Server clusters

A server cluster is a group of independent computer systems, known as nodes, running XOX or XOX, and working together as a single system to ensure that critical applications and resources remain available to clients. The nodes in a cluster remain in constant communication through the exchange of periodic messages, called heartbeats. If one of the nodes becomes unavailable as a result of failure or maintenance, another node immediately begins providing service (a process known as failover).

Server clusters can combine up to eight nodes. In addition, a cluster cannot be made up of nodes running both XOX and XOX since the different operating systems may be running incompatible versions of the Cluster service. In server clusters with more than two nodes, all nodes must run XOX or XOX, but not both. However, a server cluster can be operated with some nodes running the Microsoft® Windows® 2000 operating system and others running XOX or XOX.

Server clusters can be set up as one of three different cluster model configurations:

  • Single node server clusters can be configured with, or without, external cluster storage devices. For single node clusters without an external cluster storage device, the local disk is configured as the cluster storage device.
  • Single quorum device server clusters have two or more nodes and are configured so that every node is attached to one or more cluster storage devices. The cluster configuration data is stored on a single cluster storage device.
  • Majority node set server clusters have two or more nodes but the nodes may or may not be attached to one or more cluster storage devices. The cluster configuration data is stored on multiple disks across the cluster and the Cluster service makes sure that this data is kept consistent across the different disks.

It is recommended that you understand the advantages and limitations of the different cluster models before you configure your server cluster. For example, a majority node set cluster can tolerate fewer simultaneous node failures than an equivalent single quorum device cluster.

For more information on the three cluster models, see Choosing a cluster model.

You can use a shared SCSI or Fibre Channel device for cluster storage on server clusters running XOX or XOX. It is recommended that you use a Fibre Channel device for cluster storage in server clusters with more than two nodes. For all server clusters running the 64-bit editions of XOX or XOX, you can only use Fibre Channel hardware on the shared storage bus.

Server clusters enable users and administrators to access and manage the nodes as a single system rather than as separate computers.

  • Before creating a server cluster, see Checklists: Creating server clusters.
  • Before installing resources for a server cluster, see Checklists: Installing server cluster resources.
  • To find features that have been changed in XOX and XOX, see New ways to do familiar tasks.
  • For guidelines on securing server clusters, see Best practices for securing server clusters.
  • For tips about using server clusters, see Best practices for configuring and operating server clusters.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.

Note

  • XOX


Checklists: Creating server clusters

  • Checklist: Planning and creating a server cluster
  • Checklist: Creating a new group
  • Checklist: Creating a new resource
  • Checklist: Creating a server cluster virtual server
  • Checklist: Creating a server cluster file server
  • Checklist: Creating a server cluster print server
  • Checklist: Creating a clustered IIS Web or FTP service
  • Checklist: Creating a server cluster application server
  • Checklist: Validating your clustering system


Checklist: Planning and creating a server cluster

Caution

  • If you are using a shared storage device, when you power on and start the operating system, it is of vital importance that only one node has access to the cluster disk. Otherwise the cluster disks can become corrupted. To prevent the corruption of the cluster disks, shut down all but one cluster node, or use other techniques (for example, Logical Unit Number or LUN masking, selective presentation, or zoning) to protect the cluster disks, before creating the cluster. Once the Cluster service is running properly on one node, the other nodes can be added and configured simultaneously.

Follow these steps to plan for and create a server cluster. You can use the tutorial for Cluster Installation at the Microsoft Web site (http://www.microsoft.com/) to help you create a server cluster. If you are upgrading your server cluster, review the cluster upgrade documentation.

Planning issues to consider before you create your server cluster
Step | Reference
Review basic cluster concepts. You will need to understand nodes, failover and failback, groups, and resources before planning your server cluster.

Concepts

Server clusters overview

Glossary of Clustering terms
Review security best practices for server clusters. | Best practices for securing server clusters
Review limitations of server clusters. | Limitations of server clusters
Choose your cluster model. | Choosing a cluster model
Choose applications that can run on your server cluster. | Choosing applications to run on a server cluster
Organize your cluster applications and resources into groups based on resource dependencies, failover policies, and administrative convenience. | Planning your groups
After you choose a cluster model and determine how to group your applications and resources, you are ready to determine the hardware capacity required for each server in the cluster. | Determining server-capacity requirements
Plan your network hardware.

Planning your networking hardware

Best practices for configuring and operating server clusters

Plan your system disks.

It is recommended that the system disks on all your cluster nodes use the same drive letter.

Plan your cluster disks.

To guard against the failure of your cluster disks, it is highly recommended that you implement a hardware RAID solution.

If your cluster disk hardware includes a SCSI bus, it is important to note that the SCSI host adapters must each have a unique SCSI ID (usually the numbers 6 and 7). In addition, the SCSI bus must be properly terminated.

By default, the New Server Cluster Wizard will automatically select the smallest disk that is larger than 500 MB as the quorum resource. If no disk larger than or equal to 500 MB is available, the New Server Cluster Wizard will select the largest disk that is at least 50 MB as the quorum resource but will generate a warning. For optimal performance of the NTFS file system, make sure that the disk containing the quorum resource is at least 500 megabytes (MB) in size. It is strongly recommended that you install the quorum resource on a separate disk, by itself, so that other applications cannot affect it. Also, ensure that the quorum disk has sufficient free space so that the Cluster service can start and continue to write to the quorum log.

Hardware redundant array of independent disks (RAID)

The documentation for your storage hardware.
Actions to take when creating a server cluster
Step | Reference

Choose your cluster hardware.

Microsoft supports only complete cluster systems chosen from the Windows Catalog; it is recommended that you do not mix and match hardware components when building your cluster. Check to ensure that your hardware, including your cluster disks, is compatible with XOX or XOX.

 Compatible Hardware and Software

Best practices for configuring and operating server clusters
Verify the availability of domain services and add your servers to the domain. | Choosing a domain model

Install and configure your cluster disks.

Turn on your cluster nodes, but do not allow the operating system to start on any of the nodes. Connect your shared storage buses, completing the initial installation steps in the BIOS or EFI firmware configuration screens for your particular storage device by following the directions in the hardware documentation.

Allow the operating system to start on one node and configure the cluster disks as basic disks. Format the disks using the NTFS file system. Assign drive letters to or create mounted drives for the cluster disks on the shared bus. If you assign drive letters, the disks must have the same drive letter on all nodes in the cluster.

Caution

  • For 64-bit editions of XOX or XOX, cluster disks on a shared bus must be partitioned as Master Boot Record (MBR) and not as GUID Partition Table (GPT) disks.

The documentation for your storage hardware.

General storage configuration tips for server clusters

To connect the shared storage buses and assign drive letters
Configure network hardware.

Configuring cluster network hardware
Configure IP address settings for your network. Network Interface Controller (NIC) configuration

Private network addressing options
Gather the information required for configuring the first node in your cluster.

You will need the following:

  1. A static IP address for the cluster.
  2. Computer accounts for the cluster nodes.
  3. A user account for the Cluster service.
  4. A name for the cluster, that is, the name administrators will use for connections to the cluster. (The actual applications running on the cluster will typically have different network names.)

Caution

  • Computer accounts for the nodes must be in the same domain. It is strongly recommended that the Cluster service account be in the same domain as well.
  • It is strongly recommended that you do not use the same account for the Cluster service and applications in the cluster (for example, Microsoft SQL Server). If you do use the same account, you may not be able to later change the Cluster service password without disrupting your cluster applications.
  • The cluster name must be different from the domain name, from all computer names or virtual server names in the domain, and from other cluster names in the domain.

Domain accounts and the Cluster service

The Cluster service and TCP/IP

Create a cluster on the first node.

Use Cluster Administrator to create a cluster on the first node.

Note

  • You cannot use the Configure Your Server or Manage Your Server tools to create a cluster or administer cluster nodes.

You can use the tutorial for Cluster Installation to complete the New Server Cluster Wizard.

 To create a cluster

Microsoft Web site (http://www.microsoft.com/)

Verify that you can see the cluster disks.

Use Disk Management to verify that you can see the cluster disks.

Use Cluster Administrator to verify that the disks are all online.

 Disk Management

To bring a group online

Allow the remaining nodes to boot to the operating system then add them to the cluster.

Use Cluster Administrator to add one or more nodes to the cluster.

You can use the tutorial for Cluster Installation to complete the New Server Cluster Wizard.

 To add additional nodes to the cluster

Microsoft Web site (http://www.microsoft.com/)

Validate the cluster disks.

Use Disk Management to verify that all nodes see the same number of cluster disks.

Use Cluster Administrator to failover the cluster disks to each node in the cluster and verify that they come back online.

 Disk Management

To test whether group resources can fail over

Configure the cluster network role and type.

By default, the New Server Cluster Wizard will set up all cluster networks as mixed (public-and-private) networks. Optionally, you can change this so that the networks are set up as private networks (that is, for node-to-node communication only) or public networks (that is, for client access only).

 To change how the cluster uses a network

Configure the cluster network properties.

Place the private network at the top of the Network Priority list for internal node-to-node communication in the cluster.

 To change network priority for communication between nodes

Create your resource groups and resources.

 Checklist: Creating a new group

Checklist: Creating a new resource

Validate your clustering system.

 Checklist: Validating your clustering system


Checklist: Creating a new group

Step | Reference
Review resource groups. | Groups
Determine the name you will assign to the group. This name must be different from any other group name in the cluster. | Not applicable
(Optional) Determine the text description for the group. | Not applicable
(Optional) Determine the preferred owner for the group. | Not applicable
Use the New Group Wizard to create the group. | To create a new group
Determine the group's failover/failback policy. | Failover and failback Determining failover and move policies for groups To set group failover policy To set group failback policy


Checklist: Creating a new resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Determine the name of your resource. This name must be different from any other resource name in the cluster. | Not applicable
Determine the type of your resource. | Resource types
Determine the group to which your resource will belong. | Groups
Determine if the resource will run in a separate resource monitor. | Resource Monitors
List the possible owners of the resource. | Failover and failback
Determine the resource dependencies. | Resource dependencies
Determine the restart policy for the resource. | To specify the restart policy for a resource Failover and failback
List properties specific to your resource. | Checklists: Installing server cluster resources
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Creating a server cluster virtual server

Step | Reference
Review the concepts behind virtual servers. | Virtual servers
Use the Cluster Application Configuration Wizard to create your virtual server. | To start the Cluster Application Wizard
Configure resource dependencies in your virtual server. | Setting resource dependencies


Checklist: Creating a server cluster file server

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Determine what type of file share is appropriate for your situation.

Note

  • If you plan to maintain home folders for a large number of users on a server cluster, you do not have to create a file share resource for every home folder (which may slow down your server cluster's performance). Instead you can create a single file share for the root home folder and use the Cluster service to share the subfolders to the individual users.
File Share resource type

Using a server cluster with large numbers of file shares
Plan your resource groups. | Planning your groups
Create a new server cluster. | Checklist: Planning and creating a server cluster
Create a virtual server for your file server and a file share resource.

Checklist: Creating a new group

Checklist: Creating a server cluster virtual server

Checklist: Creating a new resource

To share subfolders on a File Share resource

To create a cluster-managed encrypted file share


Checklist: Creating a server cluster print server

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Review documentation for the Print Spooler resource type. | Print Spooler resource type
Plan your resource groups. | Planning your groups
If a server cluster does not already exist, create a new server cluster. | Checklist: Planning and creating a server cluster
Create a group, a virtual server for your print server, and a printer spooler resource. | Checklist: Creating a new group Checklist: Creating a server cluster virtual server Checklist: Creating a new resource


Checklist: Creating a clustered IIS Web or FTP service

Important

  • It is recommended that you review the information on Network Load Balancing clusters before using a server cluster to create a high-availability Web server. Depending on your needs, using a Network Load Balancing cluster to load balance the incoming client HTTP traffic might be a better solution. For more information on Network Load Balancing clusters, see Network Load Balancing clusters.

    For the most current information on server clusters and how they work with Network Load Balancing, see Updated technical information.

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Review Internet Information Service (IIS) concepts. | Internet Information Services
Install the Microsoft Distributed Transaction Coordinator (DTC) resource. Component Services Administrative Tasks Overview

Checklist: Installing a Distributed Transaction Coordinator resource
Install Internet Information Service (IIS). | Internet Information Services
Decide which internet service you will provide: FTP or Web.

If you are creating an FTP server, install the FTP service and default FTP site.

Note

  • A Web site is installed by default when you first install IIS.
Internet Information Services
Plan your resource groups. | Planning your groups
Create a new cluster. | To create a cluster
Add nodes to the cluster. | To add additional nodes to the cluster
Create a group and a virtual server for your clustered IIS service.

Checklist: Creating a new group

Checklist: Creating a server cluster virtual server
Create a Generic Script Resource for the IIS service in the virtual server resource group you created above.

XOX and XOX include 2 example Visual Basic scripts that you can use for this purpose, clusweb.vbs and clusftp.vbs. By default, these are located in the %systemroot%\system32\inetsrv directory.

Important

  • It is recommended that the Generic Script resource configured for IIS be dependent on both a Network Name resource (so that remote clients can access it) and a Physical Disk (or other storage class device) resource. The Network Name will, in turn, be dependent on the IP Address (that will correspond to the virtual root).
  • If you use a Generic Script resource to host multiple Web sites, it is recommended that you run the same version of IIS on all nodes in the cluster.

Note

  • You can run the clusweb.vbs and clusftp.vbs scripts remotely from a non-XOX or XOX computer by pointing to the %systemroot%\system32\inetsrv XOX or XOX directory where they are located.

Checklist: Installing a Generic Script resource

Setting resource dependencies

To modify resource dependencies
Configure IIS bindings.

To configure an FTP site to handle requests sent to a virtual server, ensure that the FTP site is configured to listen to the IP address of the virtual server. You can do this by assigning an IP address to an FTP site.

To configure a Web site to handle requests sent to a virtual server, ensure that the Web site is configured to listen to the IP address and/or name of the virtual server. The name of the virtual server can be used as the Host Header value for the Web site. You can do this by assigning an IP address and/or Host Header values to a Web site.

 Internet Information Services
Synchronize IIS on all nodes by using the IISconfg.vbs /copy command to copy the IIS configuration to other nodes. | Internet Information Services


Checklist: Creating a server cluster application server

Step | Reference
Review server cluster components. | Server cluster components
Review cluster resources. | Server cluster resources
Review the requirements for your application. | Your application documentation Checklist: Installing a Generic Application resource
Plan your resource groups. | Planning your groups
Create a group, a virtual server for your application, and a generic application resource. | Checklist: Creating a new group Checklist: Creating a server cluster virtual server Checklist: Creating a new resource


Checklist: Validating your clustering system

Step | Reference
One by one, take each resource group offline then bring it back online.

Note

  • The default Cluster Group (containing the quorum resource) will not go offline.
To take a group offline

To bring a group online
Test that resources can fail over by moving resource groups from one node to another. | To test whether group resources can fail over
Test the failover policies for the resource groups. | To test group failover policy
Test that the cluster can recover from node failures. | To test node failure
Test that the cluster can recover from private network failures. | To test private network failures
Review your system logs for any server cluster errors recorded by the Cluster service.

In Event Viewer, server cluster errors logged by the Cluster service show up under the Source column as "ClusSvc".

 Event Log overview


Checklists: Installing server cluster resources

  • Checklist: Installing a DHCP Service resource
  • Checklist: Installing a Distributed File System (DFS) root resource
  • Checklist: Installing a Distributed Transaction Coordinator resource
  • Checklist: Installing a File Share resource
  • Checklist: Installing a Generic Application resource
  • Checklist: Installing a Generic Script resource
  • Checklist: Installing a Generic Service resource
  • Checklist: Installing an IP Address resource
  • Checklist: Installing a Local Quorum resource
  • Checklist: Installing a Majority Node Set resource
  • Checklist: Installing a Message Queuing resource
  • Checklist: Installing a Network Name resource
  • Checklist: Installing a Physical Disk resource
  • Checklist: Installing a Print Spooler resource
  • Checklist: Installing a Volume Shadow Copy Service Task resource
  • Checklist: Installing a WINS Service resource


Checklist: Installing a DHCP Service resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review the concepts behind Dynamic Host Configuration Protocol (DHCP). | DHCP
Plan common resource settings. | Checklist: Creating a new resource
Configure location of DHCP database and backup of database files. | DHCP Service and WINS Service resource types
If you already use DHCP, and you want to retain your existing DHCP database files, move the files to the new DHCP database before bringing the new DHCP server online. | Backing up the DHCP database
Make certain that you install the DHCP Service on all nodes. | To install a DHCP server
Use the New Resource Wizard to create the resource.

Important

  • When you create a DHCP Service resource on a node, the Cluster service sets the startup type for the DHCP service on that node to Manual. The Cluster service also stops the DHCP service on all the other nodes, but, on those nodes not hosting the DHCP Service resource, the Cluster service leaves the DHCP service startup type set to Automatic. This DHCP service startup type will be set to Manual on any of the other nodes only when the DHCP Service resource fails over. In addition, if you subsequently evict a node from the cluster, the DHCP service will not be restarted on that evicted node.
To create a new resource

To configure how a service is started


Checklist: Installing a Distributed File System (DFS) root resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Review Distributed File System (DFS) information. | The Distributed File System (DFS)
Using the DFS Microsoft Management Console (MMC) snap-in, make sure that a DFS root does not already exist. | To show a root
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Distributed Transaction Coordinator resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Create or select the group you want to install the Distributed Transaction Coordinator (DTC) resource into. By default, the DTC resource will install into the first group it locates that has an IP, Name, and Physical Disk resource, unless you identify a specific group. | Checklist: Creating a new group Component Services Administrative Tasks Overview
Use the New Resource Wizard to create the resource. Make the Distributed Transaction Coordinator resource dependent on the Physical Disk resource. | To create a new resource


Checklist: Installing a File Share resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies.

Important

  • It is recommended that the File Share resource be dependent on a Physical Disk and a Network Name resource.
Groups
Review the behavior of the file share resource type. | File Share resource type
Plan common resource settings. | Checklist: Creating a new resource
Determine whether you will use the advanced properties of the File Share resource type. | File Share resource type
Use the New Resource Wizard to create the resource. | To create a new resource
Configure file share permissions using Cluster Administrator. Using Cluster Administrator

Start Cluster Administrator in Microsoft Management Console


Checklist: Installing a Generic Application resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Install your application on all nodes.

Note

  • Before attempting to cluster your application, contact the application vendor for specific installation instructions or recommendations on configuring it optimally on your server cluster.
Generic Application resource type
Note the command line for your application. | The documentation for your application.
Determine the directory in which your application needs to run. | The documentation for your application.
Determine whether your application can display windows on the node on which it runs. | The documentation for your application.
Determine which application registry keys need to be replicated.

Information on registry key replication.

Server clusters provides the ability for Generic Service and Generic Application resource types to specify registry keys below HKEY_LOCAL_MACHINE that need be replicated to all nodes in the cluster.

Some services or applications might update registry information while they are running by use of Win32 registry functions. The Cluster service provides registry checkpointing for noncluster-aware applications that may use these functions. Registry checkpointing for these resources occurs under the following conditions:

  • When you specify a new registry key for the resource, the specified key is checkpointed.
  • When the resource goes online, the registry keys are updated with the previously checkpointed information.
  • When the resource is brought offline, all the checkpoints associated with this resource are saved.
  • When the resource is online and changes are made to the registry key which is registered with the cluster server for replication, the Cluster service makes sure the updates are written to a checkpoint maintained on the quorum device.

If you manually update these registry keys while the application or service is offline, the changes may not be replicated or may be lost. To prevent this from happening, make any manual changes while the service or application resource is online.

Cluster aware applications need to make use of cluster registry functions as provided in the cluster API set when working with registry keys under HKEY_LOCAL_MACHINE\Cluster. Refer to the Windows Clustering documentation in the Platform Software Development Kit (SDK) for more information on this topic.

 The documentation for your application.
Determine whether a dependent network name needs to be substituted for the computer name.

Applications can make application program interface (API) calls to determine the name of the computer on which they are running. Making the generic application dependent on a network name resource causes the Use Network Name check box in Cluster Administrator to be selected. In such a case, the network name is returned instead of the computer name when the application makes the API call. This enables applications that are not cluster aware to continue to appear to be running on the same computer even after they move to a different cluster node.

 The documentation for your application.

For more information on API calls for server clusters, see the Microsoft Platform Software Development Kit (SDK).
Determine whether any application-specific registry keys need to be replicated on all cluster nodes.

As described previously, this pertains to applications that are not cluster-aware. An application can store data in the registry. If the application is moved but the registry data is not moved with it, the application's state is lost. If the cluster administrator specifies the root of the registry key, it enables the Cluster service to "watch" that key. The Cluster service captures the data in the key and any changes that occur. When the generic application resource is moved, the Cluster service moves the registry data to the new resource host and then brings the generic application resource online.

 The documentation for your application.
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Generic Script resource

Step | Reference
Review server cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Note the name of the generic script along with the path to the script file. | For more information on developing generic scripts, see the Microsoft Platform Software Development Kit (SDK).
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Generic Service resource

Step | Reference
Review server cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Plan common resource settings. | Checklist: Creating a new resource
Note the exact service name as it appears in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services. | The documentation for your service.
Note the startup parameters of your service. | The documentation for your service.
Ensure that the service is installed on all nodes. | Not applicable
Determine which service registry keys need to be replicated on all nodes.

Information on registry key replication

Server clusters provides the ability for Generic Service and Generic Application resource types to specify registry keys below HKEY_LOCAL_MACHINE that need to be replicated to all nodes in the cluster.

Some services or applications may update registry information while they are running by use of Win32 registry functions. The Cluster service provides registry checkpointing for noncluster-aware applications that may use these functions. Registry checkpointing for these resources occurs under the following conditions:

  • When you specify a new registry key for the resource, the specified key is checkpointed.
  • When the resource goes online, the registry keys are updated with the previously checkpointed information.
  • When the resource is brought offline, all the checkpoints associated with this resource are saved.
  • When the resource is online, and changes are made to the registry key that is registered with the cluster server for replication, the Cluster service ensures that the updates are written to a checkpoint maintained on the quorum device.

If you manually update these registry keys while the application or service is offline, the changes may not be replicated or may be lost. To prevent this from happening, make any manual changes while the service or application resource is online.

Cluster-aware applications need to make use of cluster registry functions as provided in the cluster application program interface (API) set when working with Cluster registry keys under HKEY_LOCAL_MACHINE. Refer to the Windows Clustering documentation in the Platform Software Development Kit (SDK) for more information on this topic.

 The documentation for your service.

Checklist: Installing a Generic Application resource
Determine whether a dependent network name needs to be substituted for the computer name.

Applications can make application program interface (API) calls to determine the name of the computer on which they are running. Making the generic application dependent on a network name resource causes the Use Network Name check box in Cluster Administrator to be selected. In such a case, the network name is returned instead of the computer name when the application makes the API call. Thus, applications that are not cluster aware continue to appear to be running on the same computer even after they move to a different cluster node.

 The documentation for your application.
Determine whether any application-specific registry keys need to be replicated on all cluster nodes.

This pertains to applications that are not cluster aware. An application may store data in the registry. If the application is moved, but the registry data is not moved with it, the application's state is lost. If the cluster administrator specifies the root of the registry key, it enables the Cluster service to "watch" that key. The Cluster service captures the data in the key and any changes that occur. When the generic application resource is moved, the Cluster service moves the registry data to the new resource host and then brings the generic application resource online.

 The documentation for your application.
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing an IP Address resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review TCP/IP concepts. | Concepts
Plan common resource settings. | Checklist: Creating a new resource
Obtain an Internet Protocol (IP) address and subnet mask from your network administrator.

This address must be a static IP address not already in use on the network. Make sure that the subnet mask is the same subnet mask as the one for the associated cluster network.

 IP addressing and routing
Determine whether or not NetBIOS needs to be enabled for this IP address.

If NetBIOS for the IP address is enabled, it allows a dependent network name to be published using NetBIOS. If it is not enabled, the dependent network name will only be published using DNS.

 To disable WINS/NetBT name resolution

DNS
Determine the network on which to create this resource.

Important

  • It is recommended that you create IP Address resources on a network accessible by clients, that is, a public or mixed network.
Server cluster networks
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Local Quorum resource

Step | Reference
Review server cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review the behavior of the Local Quorum resource type.

Note

  • The Local Quorum resource can be used as the quorum resource only for a single-node cluster.
Local Quorum resource type
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Majority Node Set resource

Step | Reference
Review server cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review the behavior of the Majority Node Set resource type and the cluster configurations that use this resource type.

Note

  • Only one Majority Node Set resource can exist in a server cluster.
Majority Node Set resource type

Model 3: Majority node set server cluster configuration
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Message Queuing resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review Message Queuing concepts. | Message Queuing
Plan common resource settings. | Checklist: Creating a new resource
Make sure that Microsoft Distributed Transaction Coordinator (DTC) is already installed. Component Services Administrative Tasks Overview

Checklist: Installing a Distributed Transaction Coordinator resource
Create a Physical Disk or other storage class device resource. | Checklist: Installing a Physical Disk resource
Create a Network Name resource. | Checklist: Installing a Network Name resource
Enable Kerberos authentication for that Network Name resource. | To enable Kerberos authentication for virtual servers
Use the New Resource Wizard to create the Message Queuing resource.

Make the Message Queuing resource dependent on the Network Name and Physical Disk resources created earlier.

Caution

  • You can have multiple Message Queuing resources in a server cluster. However, you can only have one Message Queuing resource per resource group.
  • If you do have multiple Message Queuing resources in a server cluster, message activity may not function as expected unless you increase the system view space memory pool size of each node by 4 MB for each instance of the Message Queuing resource. For more information, see the troubleshooting topic "The Message Queuing resource fails to handle message activity correctly which may result in resource failures" in Group and resource failure problems.

Note

  • The Message Queuing resource does not have to be located in the same resource group as the group containing the DTC resource.
  • The Message Queuing resource can come online even if the DTC resource is not online provided that there are no transactions to recover. If the DTC resource is offline, transactions are disabled; once the DTC resource comes back online, transactions are enabled.
 To create a new resource


Checklist: Installing a Network Name resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review networking concepts. | Networking
Plan common resource settings. | Checklist: Creating a new resource
Choose an Internet Protocol (IP) address resource to be associated with the network name.

If an IP address resource does not already exist, create one. If necessary, obtain the IP address from your network administrator. This must be a static IP address.

When the Network Name resource is brought online, the IP address resource with which it is associated is included when the name is registered with the various name resolution services.

To create a new resource

IP addressing and routing

To disable WINS/NetBT name resolution

DNS
Choose the name you want to publish on the network, following any naming conventions that might be in effect. | Not applicable
Use the New Resource Wizard to create the network name resource.

Make the network name resource dependent on the IP address resource.

Note

  • Optionally, you can enable Kerberos authentication and specify that DNS registration must succeed for the network name resource.
To create a new resource

To modify resource dependencies

Kerberos authentication for virtual servers


Checklist: Installing a Physical Disk resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review disk storage concepts. | Disk Management
Plan common resource settings. | Checklist: Creating a new resource
Make sure that the disk has a signature. | Disk Management
Make sure that the disk is configured as basic and not dynamic. | Disk Management
Make sure that all partitions on the disk are formatted using the NTFS file system. | Disk Management
Make sure that all partitions have a drive letter assigned or is set up as a mounted drive.

Important

  • If you use drive letters, assign drive labels that match the drive letters and make sure that you assign the same drive letter to each node in the cluster.
Disk Management

Install local storage buses and devices
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Print Spooler resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups Setting resource dependencies
Review network printing concepts. | Printing
Review print spooler resource type information. | Print Spooler resource type
Make sure that your printer can be used with TCP/IP. | To create a cluster-managed printer
Plan common resource settings. | Checklist: Creating a new resource
Use the New Resource Wizard to create the resource. | To create a new resource


Checklist: Installing a Volume Shadow Copy Service Task resource

Step | Reference
Review the general concepts for cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review the behavior of the Volume Shadow Copy Service Task resource type. | Volume Shadow Copy Service Task resource type
Plan common resource settings. | Checklist: Creating a new resource
Create or select the resource group into which you want to install the Volume Shadow Copy Service Task resource. | Checklist: Creating a new group
Use the New Resource Wizard to create the resource.

If necessary, make the Volume Shadow Copy Service Task resource dependent on other resources in the resource group.

Caution

  • If the name you provide for your Volume Shadow Copy Service Task resource is the same as an existing scheduled task, that scheduled task will be deleted when the Volume Shadow Copy Service Task resource is brought online.

Important

  • If you want to create a Volume Shadow Copy Service Task resource to manage shadow copies on a cluster node, use this procedure instead: To enable Shadow Copies of Shared Folders in a cluster. Using Cluster Administrator or cluster.exe to completely configure and manage shadow copies in a cluster is not a supported scenario.
  • The scheduled task managed by the Volume Shadow Copy Service Task resource runs under the Local System account with a default working directory of systemroot\system32.
 To create a new resource

Setting resource dependencies


Checklist: Installing a WINS Service resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review Windows Internet Naming Resource (WINS) concepts. | WINS
Plan common resource settings. | Checklist: Creating a new resource
Configure location of WINS database and backup of database files. | DHCP Service and WINS Service resource types
If you already use WINS, and you want to retain your existing WINS database files, move the files to the new WINS database before bringing the new WINS server online. | The WINS database Backup the WINS database
Make certain that you install the WINS Service resource on all nodes. | Not applicable
Use the New Resource Wizard to create the resource. | To create a new resource


New ways to do familiar tasks

The following table lists common tasks for configuring server clusters in XOX or XOX. The user interface for performing these tasks is different from the way it was in Windows 2000.

If you want to | In Windows 2000 use | In Windows Server 2003 family use
Create a new cluster. | Add or Remove Programs to install the Cluster service then use Cluster Administrator to add the first node to the cluster. | Cluster Administrator and select the Create new cluster option. For more information, see Checklist: Planning and creating a server cluster and Add the first node to the cluster.
Add nodes to a cluster. | Add or Remove Programs to install the Cluster service on each server to be added to the cluster then use Cluster Administrator locally to add each node, one by one, to the cluster. | Cluster Administrator and select the Add nodes to cluster option to add one or more nodes all at once. You can also add nodes locally or remotely. For more information, see Add additional nodes to the cluster.
Restore the cluster quorum for all nodes in the cluster. | Cluster Administrator to stop the Cluster service on all nodes. Then use Backup to restore the System State data, and finally the Clusrest.exe tool to copy the restored data to the quorum disk. | Backup to restore the System State data and select the advanced restore When restoring the Cluster Quorum, mark the restored data as Authoritative option. For more information, see To restore the cluster database on a local node.
Uninstall the Cluster service. | Add or Remove Programs to uninstall the Cluster service on each node. | Cluster Administrator to evict the last node in the cluster.
Create a Web or FTP server. | Cluster Administrator to create an IIS instance resource. Then configure the IIS bindings and use the IISSYNC tool to replicate the IIS configuration to all nodes. | Cluster Administrator to create a Generic Script resource for running the IIS service. Then configure the IIS bindings and use the IIS Backup/Restore feature to replicate the IIS configuration to all nodes. For more information, see Checklist: Creating a clustered IIS Web or FTP service.
Change network roles, names, and priorities. | The New Server Cluster Wizard and change these network properties during setup. | Cluster Administrator after setup to change the properties of the cluster networks. For more information, see To change how the cluster uses a network, To change the name or description of a network, and To change network priority for communication between nodes.
Delete a resource. | Cluster Administrator to first take the resource offline before deleting it. | Cluster Administrator to delete it. For more information, see To delete a resource.
Change the password for the Cluster service account. | Cluster Administrator to first stop the Cluster service on all nodes. Then use Active Directory Users and Computers to change the password for the account before restarting the Cluster service and bringing the nodes back online. | Cluster.exe commands to dynamically change the password on the domain controller and the cluster nodes without bringing down the entire cluster. For more information, see To change the Cluster service account password.


Best practices

  • Best practices for configuring and operating server clusters
  • Best practices for securing server clusters


Best practices for configuring and operating server clusters

The following guidelines will help you effectively use a server cluster:

Secure your server cluster.

To prevent your server cluster from being adversely affected by denial of service attacks, data tampering, and other malicious attacks, it is highly recommended that you plan for and implement the security measures detailed in Best practices for securing server clusters.

Check that your server cluster hardware is listed in the Windows Catalog.

For XOX and XOX, Microsoft supports only complete server cluster systems chosen from the Windows Catalog. To see if your system or hardware components, including your cluster disks, are compatible, see Support resources. For a geographically dispersed cluster, both the hardware and software configuration must be certified and listed in the Windows Catalog.

The network interface controllers (NICs) used in certified cluster configurations must be selected from the Windows Catalog.

It is recommended that your cluster configuration consist of identical storage hardware on all cluster nodes to simplify configuration and eliminate potential compatibility problems.

Partition and format disks before adding the first node to your cluster.

Partition and format all disks on the cluster storage device before adding the first node to your cluster. You must format the disk that will be the quorum resource. All partitions on the cluster storage device must be formatted with NTFS (they can be either compressed or uncompressed), and all partitions on one disk are managed as one resource and move as a unit between nodes.

Important

  • For 64-bit editions of XOX or XOX, cluster disks on the cluster storage device must be partitioned as MBR and not as GUID partition table (GPT) disks.

Correctly set up your server cluster's networks.

Follow the guidelines below to reduce network problems in your server cluster:

  • Use identical network adapters in all cluster nodes, that is, make sure each adapter is the same make, model, and firmware version.
  • Use at least two interconnects. Although a server cluster can function with only one interconnect, at least two interconnects are necessary to eliminate a single point of failure and are required for the verification of original equipment manufacturer (OEM) clusters.
  • Reserve one network exclusively for internal node-to-node communication (the private network). Do not use teaming network adapters on the private networks.
  • Set the order of the network adapter binding as follows:
    1. External public network
    2. Internal private network (Heartbeat)
    3. [Remote Access Connections]

    For more information, see To modify the protocol bindings order.

  • Manually set the speed and duplex mode for multiple speed adapters to the same values and settings. If the adapters are connected to a switch, ensure that the port settings of the switch match those of the adapters. For more information, see To change network adapter settings.
  • Use static IP addresses for each network adapter on each node.
  • For private networks, define the TCP/IP properties for static IP addresses following the guidelines at Private network addressing options. That is, specify a class A, B, or C private address.
  • Do not configure a default gateway or DNS or WINS server on the private network adapters. Also, do not configure private network adapters to use name resolution servers on the public network; otherwise, a name resolution server on the public network might map a name to an IP address on the private network. If a client then received that IP address from the name resolution server, it may fail to reach the address because no route from the client to the private network address exists.
  • Configure WINS and/or DNS servers on the public network adapters. If Network Name resources are used on the public networks, set up the DNS servers to support dynamic updates; otherwise, the Network Name resources may not fail over correctly. For more information, see To configure TCP/IP settings.
  • Configure a default gateway on the public network adapters. If there are multiple public networks in the cluster, configure a default gateway on only one of these. For more information, see To configure TCP/IP settings.
  • Clearly identify each network by changing the default name. For example, you could change the name of the private network connection from the default Local Area Connection to Private Cluster Network.
  • Change the role of the private network from the default setting of All communications (mixed network) to Internal cluster communications only (private network) and verify that each public network is set to All communications (mixed network). For more information, see To change how the cluster uses a network.
  • Place the private network at the top of the Network Priority list for internal node-to-node communication in the cluster. For more information, see To change network priority for communication between nodes.

Do not install applications into the default Cluster Group.

Do not delete or rename the default Cluster Group or remove any resources from that resource group.

The default Cluster Group contains the settings for the cluster and some typical resources that provide generic information and failover policies. This group is essential for connectivity to the cluster. It is therefore very important to keep application resources out of the default Cluster Group and so prevent clients from connecting to the Cluster Group's IP address and network name resources. If a resource for an application is added to this group and the resource fails, it may cause the cluster group to fail also, therefore reducing the overall availability of the entire cluster. It is highly recommended that you create separate resource groups for application resources.

For more information, see Planning your groups and Checklist: Planning and creating a server cluster.

Back up your server cluster.

To be able to effectively restore your server cluster in the event of application data or quorum loss, or individual node or complete cluster failure, follow these steps when preparing backups:

  1. Perform an Automated System Recovery (ASR) backup on each node in the cluster.
  2. Back up the cluster disks from each node.
  3. Back up each individual application (for example, Microsoft Exchange Server or Microsoft SQL Server) running on the nodes.

Note

  • By default, Backup Operators do not have the user rights necessary to create an Automated System Recovery (ASR) backup on a cluster node. However, Backup Operators can perform this procedure if that group is added to the security descriptor for the Cluster service. You can do that using Cluster Administrator or cluster.exe. For more information, see To give a user permissions to administer a cluster and Cluster.

For more information, see Backing up and restoring server clusters. For more information on backing up applications in a cluster, see the documentation for that application.

Maintain a backup of the RAID controller.

In a single quorum device server cluster, the RAID controller is a single point of failure. Always maintain a backup of the RAID controller configuration in case the RAID controller is replaced.

Do not use APM/ACPI Power saving features.

APM/ACPI Power saving features must not be enabled on server cluster members. A cluster member that turns off disk drives or enters "system standby" or "hibernate" mode can initiate a failure in the cluster. If multiple cluster nodes have power saving enabled, this can result in the entire cluster becoming unavailable.

Cluster members must use any power scheme that sets the Turn off hard disks option to Never, for example, the Always On power scheme. For more information on choosing a power scheme (located under Power Options in Control Panel), see To choose a power scheme.

For cluster nodes without Terminal Services installed, see To configure the Always On power scheme without Terminal Services installed.

For cluster nodes with Terminal Services installed, see To configure the Always On power scheme with Terminal Services installed.

Note

  • Installing Terminal Services on a system reduces the power management options available to the user. The System standby and System hibernates options are not available.

Give the Cluster service account full rights to administer computer objects if Kerberos authentication is enabled for virtual servers.

If you enable Kerberos authentication for a virtual server's Network Name resource, the Cluster service account does not need full access rights to the computer object associated with that Network Name resource. The Cluster service can use the default access rights given to members of the authenticated users group, but certain operations (for example, renaming the computer object) will be restricted. It is recommended that you work with your domain administrator to set up appropriate administration rights and permissions for the Cluster service account.

For more information, see Kerberos authentication for virtual servers.

Do not install scripts used by Generic Script resources on cluster disks.

It is recommended that you install script files used by Generic Script resources on local disks, not on cluster disks. Incorrectly written script files can cause the cluster to stop responding. Installing the script files on a local disk makes it easier to recover from this scenario. For guidelines on writing scripts for the Generic Script resource, see the Microsoft Platform Software Development Kit (SDK). For information on troubleshooting Generic Script resource issues, see article Q811685, "A Server Cluster with a Generic Script Resource Stops Responding" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)


Best practices for securing server clusters

Use the following guidelines to help keep your server cluster from being adversely affected by denial of service attacks, data tampering, and other malicious attacks:

Restrict physical access to the server cluster and related infrastructure components to trusted personnel.

Only allow authorized personnel to have physical access to the server cluster nodes and related infrastructure components (for example, the network and storage components). For more information about standard best practices for securing servers, see Best practices.

Secure your cluster networks.

For public or mixed networks: Ensure that all servers (for example, infrastructure servers such as DNS or WINS servers) that are attached to the cluster subnet (or any other subnet) are secure and trusted. Also, use a firewall to protect your cluster from unauthorized client access.

For private networks: Physically disjoint the private network(s) from other networks. Specifically, do not use a router, switch, or bridge to join a private cluster network to any other network. Do not include other network infrastructure or application servers on the private network subnet.

If heartbeat messages that are carried by private or mixed networks are disrupted (for example, by unauthorized users flooding the cluster networks), the cluster's reaction to these false failures may affect not only groups with IP address resources, but also the health of the cluster nodes. Repeated failover of critical cluster resources (for example, resources associated with Microsoft Exchange Server) may cause clients to lose access to the cluster.

Administer cluster nodes remotely only from trusted, secure computers.

If the remote computers are compromised, untrustworthy or malicious code can be started unknowingly by the cluster administration tools and adversely affect the cluster itself.

Do not set the Cluster service account to be a member of the domain administrator group.

By giving the minimal possible administration rights and permissions to the Cluster service account, you avoid potential security issues if that account is compromised. For more information on the administration rights and permissions required by the Cluster service account, see To change the account under which the Cluster service runs.

Do not use the Cluster service account to administer the cluster.

This will limit exposure to the account with fewer administration rights and permissions than the Cluster service account. For more information on using another user account to administer a cluster, see To give a user permissions to administer a cluster.

Use different accounts for the Cluster service and applications in the cluster.

This will limit exposure to the application and not the cluster account if an application account is compromised. In addition, if you use cluster.exe to change the password for the Cluster service account and one or more applications also use that account, your cluster applications may not function correctly. For more information, see To change the Cluster service account password.

Use different Cluster service accounts for multiple clusters.

This will limit exposure to one cluster only if a Cluster service account is compromised.

Remove the Cluster service account after evicting all the nodes in your cluster.

The cluster administration tools will not automatically delete the Cluster service account when all nodes have been evicted from the cluster. The Cluster service account has a high level of administration rights and permissions and that can present potential security issues if it is compromised; it is highly recommended that you remove this account from the local Administrators group if you no longer have use for it. However, because the administrative rights and permissions for the Cluster service account are granted locally on each cluster node and not domain wide, the impact of a compromised account is limited to just the cluster nodes. For more information on deleting user accounts, see Delete a local user account.

Audit security-related events in the cluster.

To ensure that only trusted personnel have user rights and permissions to administer the cluster and to track additions of unauthorized user accounts, audit changes to the local Administrators group. Note that, by default, when you create a server cluster or add nodes, the Cluster service account is added to the local Administrators group on each node. For more information on auditing security events, see Auditing security events.

Limit and audit access to shared data (for example, files and folders on cluster disks).

If you want to audit access to shared data, enable auditing on all cluster nodes. For more information, see Securing shared data in a cluster.

Limit client access to cluster resources.

Use Windows Server 2003 family security features to control client access to cluster resources as described in Limiting client access to cluster resources.

Limit access to the quorum disk and ensure that the quorum disk always has sufficient free space.

To help reduce the risk of unauthorized reads and writes to the quorum disk, it is highly recommended that you give access to the quorum disk only to the Cluster service account and members of the local Administrators group. For the Cluster service to start and continue to write to the quorum log, the quorum disk must have sufficient free space. It is recommended that the quorum disk be at least 500 megabytes (MB) in size. For more information, see Checklist: Planning and creating a server cluster and Disk resource security.

Ensure that all applications running in the cluster are from a trusted source and that access to the cluster disks is restricted only to applications that are managed as a cluster resource.

For more information, see Disk resource security.

Secure script files called by Generic Script resources.

Use NTFS file-level security for execute permissions on script files and permissions for APIs called in those scripts. For more information, see Limiting client access to cluster resources.

Ensure that applications called by Generic Application resources are from a trusted source and that files, registry checkpoints, and other resources needed for those applications are in a secure location.

For more information, see Limiting client access to cluster resources.

Secure the cluster configuration log files created when remotely administering a cluster.

After using the New Server Cluster Wizard and the Add Nodes Wizard from a remote computer, the cluster configuration log file generated by those wizards is saved to the remote computer (at %systemroot%\system32\LogFiles\Cluster\ClCfgSrv.log). This log file contains important information about the cluster. Restrict access to that file to cluster administrators and the Cluster service account. For more information, see To set, view, change, or remove permissions on files and folders.

Note

  • If you do not have administrative rights and permissions on the node on which you are using the New Server Cluster Wizard or Add Nodes Wizard, the log file will be written to the local %Temp% directory.

Do not copy files to the local cluster directories in a majority node set cluster.

In a majority node set server cluster, each node maintains a copy of the quorum database in the cluster directories located at %systemroot%\Cluster\MNS.%ResourceGUID%$\%ResourceGUID%$\MSCS. If you put files in the directories below the \Cluster directory, and then delete the Majority Node Set resource, those files will be deleted by the Cluster service.

Do not change the default security settings on the HKEY_LOCAL_MACHINE system registry subtree.

By default, only members of the Administrators group in the Builtin folder and the local system account have Full Control of the HKEY_LOCAL_MACHINE system registry subtree. If this registry subtree is compromised, some resources (for example, the Generic Script resource) may fail to start. For more information on securing the system registry, see Maintain registry security.

For more information on security in a server cluster, see Managing security in a cluster.


How to...

  • Create a cluster and manage nodes
  • Create and administer file and print server clusters
  • Manage accounts and domains in a cluster
  • Manage the cluster configuration and diagnostic logs
  • Perform advanced administrative tasks
  • Manage groups
  • Manage resources
  • Use Cluster Administrator
  • Manage networks
  • Manage cluster hardware
  • Back up and restore server clusters
  • Test cluster failures and failover policies


Create a cluster and manage nodes

  • Create a cluster
  • Add additional nodes to the cluster
  • Evict a node from the cluster
  • Repair a node without evicting it from the cluster
  • Pause a node
  • Resume a node
  • Stop the Cluster service
  • Start the Cluster service
  • Set the Cluster service to only start manually


Create a cluster

Microsoft Windows graphic

To create a cluster

  1. Open Cluster Administrator.
  2. In the Open Connection to Cluster dialog box that appears, in Action, select Create new cluster, then click OK.
  3. The New Server Cluster Wizard appears. Click Next to continue.

    4. Important

    • During the cluster creation process (using the Quorum button on the Proposed Cluster Configuration page) you will be able to select a quorum resource type (that is, a Local Quorum resource, Physical Disk or other storage class device resource, or Majority Node Set resource). For information on how these quorum resource types relate to the different cluster models, see "Choosing a cluster model" in Related Topics.
  4. Upon completion of the New Server Cluster Wizard, click Finish.

Caution

  • If you are using a shared storage device, when you power on and start the operating system, it is of vital importance that only one node has access to the cluster disk. Otherwise the cluster disks can become corrupted. To prevent the corruption of the cluster disks, shut down all but one cluster node, or use other techniques (for example, Logical Unit Number or LUN masking, selective presentation, or zoning) to protect the cluster disks, before creating the cluster. Once the Cluster service is running properly on one node, the other nodes can be added and configured simultaneously.
  • When creating a server cluster, all nodes in the cluster must have the same system default locale. That is, the language and country or region selected during the installation of the operating system on each node must be the same. For more information on changing the system default locale, see "To change number, currency, time, and date settings" in Related Topics.

Important

  • When you create a cluster, Physical Disk resources will be automatically created for cluster disks that use drive letters. However, if your cluster disks use mount points, Physical Disk resources will not be automatically created for those disks; you must manually create disk resources for cluster disks that use mount points. For more information on how to do this, see "Checklist: Installing a Physical Disk resource" in Related Topics.

Notes

  • XOX
  • XOX
  • You can also open the New Server Cluster Wizard from the File menu, by clicking New, then clicking Cluster.
  • You can safely cancel and restart the installation process at any time.
  • A majority node set server cluster is best used in controlled, targeted scenarios, as part of a cluster solution offered by your Original Equipment Manufacturer (OEM), Independent Software Vendor (ISV), or Independent Hardware Vendor (IHV). The single quorum device server cluster, the standard cluster model available in Windows NT and Windows 2000, will still cover the vast majority of your cluster deployment needs.
  • Of the default resource types, only the Physical Disk, Local Quorum, or Majority Node Set resource can be a quorum resource. However, third party vendors can supply other storage class resource types that are quorum capable.
  • To create and configure a cluster after an unattended setup, run a script to invoke the cluster /create: command and supply all the necessary configuration information on the command line. For information about unattended setup, see "Planning for unattended setup" in Related Topics. For more information on the cluster command line syntax, see "Cluster" in Related Topics.

Related Topics


Add additional nodes to the cluster

Microsoft Windows graphic

To add additional nodes to the cluster

  1. Open Cluster Administrator.
  2. In the Open Connection to Cluster dialog box that appears, in Action, select Add nodes to cluster. Then in Cluster or server name, either type the name of an existing cluster, select a name from the drop-down list box, or click Browse to search for an available cluster.
  3. Click OK to continue.
  4. The Add Nodes Wizard appears. Click Next to continue.
  5. Upon completion of the Add Nodes Wizard, click Finish.

Caution

  • If you are using a shared storage device, when you power on and start the operating system, it is of vital importance that only one node has access to the cluster disk. Otherwise the cluster disks can become corrupted. To prevent the corruption of the cluster disks, shut down all but one cluster node, or use other techniques (for example, Logical Unit Number or LUN masking, selective presentation, or zoning) to protect the cluster disks, before creating the cluster. Once the Cluster service is running properly on one node, the other nodes can be added and configured simultaneously.

Notes

  • XOX
  • XOX
  • You can also add a node to an existing cluster from the File menu, by first clicking Open Connection to connect to an existing cluster. Then, you can open the Add Nodes Wizard from the File menu, by clicking New, then Node.
  • You can safely cancel and restart the installation process.
  • If the computer you are logged onto is already a node on an existing cluster, Cluster Administrator will connect to that cluster by default.
  • After you have added new nodes to a server cluster, use Cluster Administrator to fail over the cluster disks and verify that they come back online. For information on how to do this, see "To test whether group resources can fail over" in Related Topics.
  • To add nodes to an existing cluster after an unattended setup, run a script to invoke the cluster /add: command and supply all the necessary configuration information on the command line. For information about unattended setup, see "Planning for unattended setup" in Related Topics. For more information on the cluster command line syntax, see "Cluster" in Related Topics.

Related Topics


Evict a node from the cluster

Microsoft Windows graphic

To evict a node from the cluster

  1. Close all applications on the node that is to be removed.
  2. Open Cluster Administrator.
  3. Review the failover policies of the resource groups on the node to be evicted.

    For information on how to do this, see "Determining failover and move policies for groups" in Related Topics.

  4. If necessary, move all groups on the node to be evicted to another node or nodes in the cluster.

    For information on how to do this, see "To move a group to another node" in Related Topics.

  5. Select the node to be evicted.
  6. Stop the Cluster service if the node being evicted is not the last node in the cluster. That is, on the File menu, click Stop Cluster Service.

    For information on how to do this, see "To stop the Cluster service" in Related Topics.

    If the node being evicted is the last node in the cluster, proceed to the next step.

  7. On the File menu in Cluster Administrator, click Evict Node.

Caution

  • Prior to evicting a node, check with application vendors to determine whether your applications require unclustering.
  • Application-specific data may be lost if you do not close your applications before you perform this procedure.

Important

  • Evicting the last node from the server cluster will not automatically delete the Cluster service account. It is highly recommended that you remove this account from the local Administrators group if you no longer have use for it. However, because the administration rights and permissions for the Cluster service account are granted locally on each cluster node and not domain wide, the impact of a compromised account is limited to just the cluster nodes. For more information, see Best practices for securing server clusters.

Notes

  • XOX
  • XOX
  • In some cases you may be unable to stop the Cluster service on a node or evict the last node from the cluster, for example, if you are administering a mixed-version server cluster from a Windows 2000 node and try to evict a XOX or XOX node. In these cases, you can manually remove the configuration of the Cluster service on that node by typing cluster node node name /force[cleanup] at the command line. For more information on the cluster node command-line options, see Related Topics.
  • When you evict a node from the cluster, that node is configured as a stand-alone node (that is, not a cluster node). The clustering software remains installed on the node. You can re-add the evicted node to this cluster or create a new cluster on that node at any time.
  • Typically, you remove a node from a cluster when testing, redeploying, or replacing a node.

Related Topics


Repair a node without evicting it from the cluster

Microsoft Windows graphic

To repair a node without evicting it from the cluster

  1. Open Cluster Administrator.
  2. In the console tree, click the node requiring repair.
  3. On the File menu, click Stop Cluster Service.
  4. If the node must be rebooted after being repaired, set the Cluster service to start manually.

    For more information, see "To set the Cluster service to only start manually" in Related Topics.

  5. Perform repair operations on the node.
  6. On the File menu, click Start Cluster Service to restart the Cluster service on that node.

Notes

  • XOX
  • XOX

Related Topics


Pause a node

Microsoft Windows graphic

To pause a node

  1. Open Cluster Administrator.
  2. In the console tree, click the node.
  3. On the File menu, click Pause Node.

Notes

  • XOX
  • XOX
  • When you pause a node, existing groups and resources stay online, but additional groups and resources cannot be brought online on the node. Pausing a node is used for maintenance and testing.

Related Topics


Resume a node

Microsoft Windows graphic

To resume a node

  1. Open Cluster Administrator.
  2. In the console tree, click the node.
  3. On the File menu, click Resume Node.

Notes

  • XOX
  • XOX
Related Topics


Stop the Cluster service

Microsoft Windows graphic

To stop the Cluster service

  1. Open Cluster Administrator.
  2. In the console tree, click the node.
  3. On the File menu, click Stop Cluster Service.

Notes

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. In addition, your account must be added to the security descriptor for the Cluster service. To do this, you can use Cluster Administrator or cluster.exe. For more information, see "To give a user permissions to administer a cluster" and "Cluster" in Related Topics. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • When you stop the Cluster service on a node, you prevent clients from accessing cluster resources through that node. In this event, all groups move to another node (if the failover policies allow it).

    This set of circumstances may also affect the availability of the cluster. For example, if the node to which the groups failed over fails, and your cluster consists of only two nodes, there will be no other node available to which the groups can then fail over.

  • This procedure, stopping the Cluster service, can also be performed in Computer Management, which may be necessary if Cluster Administrator fails. You can also start the Cluster service in Computer Management.
Related Topics


Start the Cluster service

Microsoft Windows graphic

To start the Cluster service

  1. Open Cluster Administrator.
  2. In the console tree, click the node.
  3. On the File menu, click Start Cluster Service.

Notes

  • To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. In addition, your account must be added to the security descriptor for the Cluster service. To do this, you can use Cluster Administrator or cluster.exe. For more information, see "To give a user permissions to administer a cluster" and "Cluster" in Related Topics. As a security best practice, consider using Run as to perform this procedure.
  • XOX
  • You can also start the Cluster service from Computer Management. For more information, see "To set the Cluster service to only start manually" in Related Topics.
Related Topics


Set the Cluster service to only start manually

Microsoft Windows graphic

To set the Cluster service to only start manually

  1. Open Computer Management.
  2. In the console tree, click Services.

    Where?

    • Computer Management
    • Services and Applications
    • Services
  3. In the details pane, click Cluster Service.
  4. On the Action menu, click Properties.
  5. In Startup type, select Manual, and then click OK.

Notes

  • XOX
  • XOX
  • To start the Cluster service even if there are problems with the quorum resource, you can use fixquorum as a start parameter. That is, in Start parameters, type /fixquorum, and then click Start.
Related Topics


Create and administer file and print server clusters

  • Create a cluster-managed printer
  • Create a cluster-managed file share
  • Create a cluster-managed encrypted file share
  • Share subfolders on a File Share resource
  • Set client-side caching for a File Share resource
  • Enable Shadow Copies of Shared Folders in a cluster


Create a cluster-managed printer

Microsoft Windows graphic

To create a cluster-managed printer

  1. Open Cluster Administrator.
  2. Create a virtual server, that is, a resource group containing a Network Name resource (where the Network Name resource is the name of a virtual server), an IP address resource, and a Physical Disk resource, if these do not already exist.

    For more information on creating a new resource group and resources, see "To create a new group" and "To create a new resource" in Related Topics.

    For more information, see "Virtual servers" in Related Topics.

  3. Create a Print Spooler resource in that virtual server and make it dependent on the Network Name and Physical Disk resources.

    Important

    • These two resources are required dependencies for the Print Spooler resource.

    For more information, see "Setting resource dependencies" and "To modify resource dependencies" in Related Topics.

  4. Bring the virtual server containing the Print Spooler resource online.

    For more information, see "To bring a group online" in Related Topics.

  5. Install printer drivers for your printer on the virtual server.

    To install printer drivers on the virtual server:

    1. Click Start and then click Run.
    2. In the Run dialog box, type \\MyVirtualServer where MyVirtualServer is the name of the virtual server that the print spooler resource depends on.

      The virtual server opens.

    3. Open Printers and Faxes, right click and select Server Properties, then click the Drivers tab.
    4. Install the printer drivers.

    Important

    • The port monitor must be installed on all nodes in the cluster before installing printer drivers on the virtual server. For the Windows Server 2003 family, the port monitor for the Standard TCP/IP Port is installed by default with the operating system. For two other types of ports, you must first install the appropriate port monitor on each node before installing the printer drivers, printer port, and printer queue on the virtual server.
      1. LPR Ports: The LPR port monitor files are shipped on the Windows Server 2003 family media. For more information on installing the LPR port monitor and adding it to the list of Available port types for a node, see "To add a port" in Related Topics.
      2. Custom IHV Ports: Printer drivers from Independent Hardware Vendors (IHVs) may include a custom IHV port monitor that must first be installed on each node. To install the IHV port monitor on each node, install the driver package on each virtual server in the cluster. Contact your IHV to verify that the third party port monitor is compatible with the Cluster service before installing on the cluster nodes.

    For more information, see "To add printer drivers for other versions of Windows" in Related Topics.

  6. Install a printer port for your printer on the virtual server.

    To install a printer port on the virtual server:

    1. Click Start and then click Run.
    2. In the Run dialog box, type \\MyVirtualServer where MyVirtualServer is the name of the virtual server that the print spooler resource depends on.

      The virtual server opens.

    3. Open Printers and Faxes, right click and select Server Properties, then click the Ports tab.
    4. Add a port.

    For more information, see "To add a port" in Related Topics.

  7. Add a print queue to the virtual server.

    To install a print queue on the virtual server:

    1. Open the remote printers folder of the virtual server.
    2. Use the Add Printer Wizard to add a new print queue.

Notes

  • XOX
  • XOX
  • You can use the Add Printer Wizard to combine steps 5 through 7 above into a single step by adding the printer drivers, printer port, and print queue successively. However, before using the Add Printer Wizard in this way, make sure that the appropriate port monitor is already installed on all nodes in the cluster.
  • Not all printer ports may be used in a server cluster. LPR and Standard TCP/IP Port, both provided with the Windows Server 2003 family, may be used in a server cluster. Check your printer documentation to verify that your printer can use one of these two ports.
  • To share out the printer, you must share out the print queue from the virtual server itself and not from the individual nodes.

Related Topics


Create a cluster-managed file share

Microsoft Windows graphic

To create a cluster-managed file share

  1. Using Windows Explorer, create a folder on the cluster disk.

    Caution

    • Do not create a share for this folder.
  2. Verify that the Cluster service account has Full Control rights to this folder for the NTFS file system.

    For more information on setting folder permissions, see "To set, view, change, or remove file and folder permissions" in Related Topics.

  3. Open Cluster Administrator.
  4. Create a Physical Disk resource for the drive on which the folder is located, a Network Name resource, and an IP Address resource, if these do not already exist, and place them in the same resource group.
  5. Create a File Share resource in the same resource group as the resources above.

    By default, Cluster Administrator will create a Normal File Share resource.

  6. Optionally, click Advanced to change the File Share resource type from Normal to DFS root or Share subdirectories.

    For more information on these three File Share resource types, see "File Share resource type" in Related Topics.

    Important

    • If the file share is configured as a DFS root, it must be dependent on a Network Name resource.
  7. Although it is not required, it is recommended that you set up the File Share resource so that it has a dependency on the Physical Disk resource as well as the Network Name resource.

    For more information on creating a new resource and setting up a dependency, see "To create a new resource" in Related Topics.

  8. In the details pane, click the File Share resource that you created, then on the File menu, click Properties.
  9. On the Parameters tab in Path, type the path to the folder whose subfolders you want to share.
  10. To configure file share permissions, click Permissions.

    For more information about setting permissions, including NTFS permissions, see "To set permissions on a shared resource" in Related Topics.

  11. On the File menu, click Bring online.

Caution

  • Always use the Cluster Administration tools and not Windows Explorer to manage these file shares. Changes made using Windows Explorer will be lost when these file shares fail over to other nodes in the cluster.

Notes

  • XOX
  • XOX

Related Topics


Create a cluster-managed encrypted file share

Microsoft Windows graphic

To create a cluster-managed encrypted file share

  1. Open Cluster Administrator.
  2. Create a cluster-managed file share.

    For more information, see "To create a cluster-managed file share" in Related Topics.

  3. In the console tree, double-click Groups, and then click the group that contains the File Share resource that you created in step 2.
  4. In the details pane, click the Network Name resource in that you will use to connect to this file share.
  5. On the File menu, click Take Offline.
  6. On the File menu, click Properties.
  7. On the Parameters tab, select Enable Kerberos Authentication, and then click OK.
  8. In the details pane, click the Network Name resource for the file share.
  9. On the File menu, click Bring Online.
  10. On the domain controller, configure all accounts used by the cluster nodes to be trusted for delegation.

    For more information, see "To allow a user to be trusted for delegation" in Related Topics.

    11. Important

    • The group containing the file share resource is a virtual server because it contains a Network Name and an IP Address resource. All accounts used to connect to this virtual server must also be trusted for delegation.
  11. On the domain controller, enable roaming profiles for all users or service accounts that store data in the folder managed by the File Share resource.

    For more information, see "To create a roaming user profile" in Related Topics.

    12. Important

    • Enabling roaming profiles ensures that the encryption keys for a folder are still valid even when the File Share resource managing that folder fails over.
  12. Enable encryption on the folder managed by the File Share resource.

    For more information, see "To encrypt a file or folder" in Related Topics.

Note

  • XOX

Related Topics


Share subfolders on a File Share resource

Microsoft Windows graphic

To share subfolders on a File Share resource

  1. Open Cluster Administrator.
  2. Create a File Share resource.

    For more information on creating a new resource, see Related Topics.

  3. In the console tree, double-click Groups, and then click the group that contains the File Share resource that you created in step 2.
  4. In the details pane, click the File Share resource that you created. On the File menu, click Properties.
  5. On the Parameters tab in Path, type the path to the folder whose subfolders you want to share.
  6. To configure file share permissions, click Permissions.

    For more information about setting permissions, including NTFS permissions, see "To set permissions on a shared resource" in Related Topics.

  7. Click Advanced, and then click Share subdirectories to enable the combo file share option that allows File Share resources to share subfolders. If you want to prevent users from seeing the subdirectory shares when they browse the network, click Hide subdirectories shares, and then click OK.

    8. For more information about file and printer sharing, see "File and Printer Sharing for Microsoft networks" in Related Topics.

  8. On the File menu, click Bring online.

Notes

  • XOX
  • XOX
  • The combo file share option permits a File Share resource to share subfolders. Subfolders of a combo file share are shared using the folder name. You cannot specify a name for a subfolder share. The only way to change a subfolder file share name is to change the subfolder name (for example, using Windows Explorer). Changing the name of a shared subfolder breaks the file share temporarily. The subfolder file share will be unavailable for the time specified by the File Share resource Is Alive poll interval. The subfolder will be shared again the next time the File Share resource Is Alive poll is called.
  • If you select the Hide subdirectories shares option you do not have to type $ as the last character when specifying the file share name. The File Share resource will automatically hide the subdirectories when you select the Hide subdirectories shares option.
  • For more information, see article Q256926, "Implementing Home Folders on a Server" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

Related Topics


Set client-side caching for a File Share resource

Microsoft Windows graphic

To set client-side caching for a File Share resource

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the appropriate File Share resource.
  4. On the File menu, click Properties.
  5. Click the Parameters tab, then click the Caching button.
  6. Select the Allow caching of files in this shared folder check box to enable client-side caching for this File Share resource.
  7. In Setting, select the appropriate client-side caching setting as shown in the table below.

    Caching setting in Cluster Administrator | Command line option in cluster.exe (cluster resource) | Description
    Allow caching of files in this shared folder is not enabled | CSCCache is set to 48 | Client-side caching is disabled for all files on the file share.
    Automatic caching of programs and documents | CSCCache is set to 32 | Client-side caching is disabled for those files that are only opened, but not modified.
    Automatic caching of documents | CSCCache is set to 16 | Changes in all files opened on the client will be reconciled between the client and the server cluster.
    Manual caching of documents | CSCCache is set to 0 | Changes in only those files specifically identified on the file share will be reconciled between the client and the server cluster.

Notes

  • XOX
  • XOX
  • Client-side caching allows network users to access files on clustered file shares, even when the client computer is disconnected from the network, by caching these offline files on the client computer. You can also set the client-side caching for a File Share resource at the command line by using the corresponding cluster resource command option as shown in the table above. For more information, see "Cluster resource" in Related Topics.
  • For more information on setting up your computer to use offline files, see "Sharing a drive or folder overview" in Related Topics.

Related Topics


Enable Shadow Copies of Shared Folders in a cluster

Microsoft Windows graphic

To enable Shadow Copies of Shared Folders in a cluster

  1. On the cluster node where you want to enable Shadow Copies of Shared Folders, create a cluster-managed file share.
  2. Set up the File Share resource so that it has a dependency on the Physical Disk resource that manages the shadow copies and designated storage volumes, as well as the Network Name resource for the file share.

    For more information, see "To create a cluster-managed file share" in Related Topics below.

    Important

    • If the shadow copy volume and the designated storage volume are on separate disks, the Physical Disk resources that manage those volumes must both be in the same resource group.
  3. Open Computer Management.
  4. In the console tree, right-click Shared Folders, select All Tasks, and click Configure Shadow Copies.

    5. Where?

    • Computer Management
    • System Tools
    • Shared Folders
  5. Click the volume where you want to enable Shadow Copies of Shared Folders, and then click Enable.

    Important

    • The Computer Management tool automatically generates a scheduled task to create the shadow copies on the storage volume and a Volume Shadow Copy Service Task resource to manage that scheduled task. It also creates a dependency on the Physical Disk resource that manages the storage volume containing the shadow copies. For more information on the default settings for the Volume Shadow Copy Service Task resource created when you enable Shadow Copies of Shared Folders, see "Using Shadow Copies of Shared Folders in a server cluster" in Related Topics below.

Important

  • If the shadow copy volume and the designated storage volume are on separate disks, enabling Shadow Copies of Shared Folders will automatically make the Physical Disk resource that manages the shadow copy volume dependent on the Physical Disk resource that manages the storage volume.
  • When you enable shadow copies, the shadow copy volumes (and all other resources directly or indirectly dependent on the disk) go offline for a brief period while the resource dependencies are created. The shadow copy volumes are not accessible to applications and users while they are offline.

Notes

  • XOX
  • XOX
  • You can also access Shadow Copies of Shared Folders by right-clicking a fixed NTFS volume in My Computer or in the Disk Management snap-in details pane (in Computer Management). Click Properties, and then click the Shadow Copies tab.
  • You can use the Disk Management snap-in to manage Shadow Copies of Shared Folders on remote servers as well. In the Computer Management console tree, right-click Disk Management, point to All Tasks, and then click Configure Shadow Copies.
  • By enabling Shadow Copies of Shared Folders, you also create a default schedule and settings for subsequent shadow copies. To make changes to these defaults, click Settings.
  • You can only enable Shadow Copies of Shared Folders on a per-volume basis; that is, you cannot select specific shared folders and files on a volume to be copied or not copied.
  • The scheduled task that is automatically created when you enable shadow copies on a cluster node will only appear in the Scheduled Tasks folder when the associated Volume Shadow Copy Service Task resource is online. If you want to change the schedule, use Computer Management; do not use the Scheduled Tasks folder.

Related Topics


Manage accounts and domains in a cluster

  • Change the account under which the Cluster service runs
  • Change the Cluster service account password
  • Give a user permissions to administer a cluster
  • Move a server cluster to another domain


Change the account under which the Cluster service runs

Microsoft Windows graphic

To change the account under which the Cluster service runs

  1. Stop the Cluster service on all nodes:
    • Make sure the account has membership in the local Administrators group on all nodes.
    • Open Local Security Policy and grant the following rights to the account, or to the local Administrators group, on all nodes:

      Where?

      • Security Settings
      • Local Policies
      • User Rights Assignments
      • Act as part of the operating system
      • Back up files and directories
      • Restore files and directories
      • Adjust memory quotas for a process
      • Log on as a service
      • Increase scheduling priority

      By default, the Cluster service account inherits the following user rights as a result of being a member of the local Administrators group:

      • Manage auditing and security log
      • Debug programs
      • Impersonate a client after authentication

      If your organization has removed these user rights from the default set of privileges assigned to the local Administrators group, you need to specifically assign these user rights to the Cluster service account.

    • Open Computer Management.
    • In Computer Management, double-click Services and Applications, and then click Services.
    • In the details pane, click Cluster Service.
    • On the Action menu, click Stop.
  2. Repeat step 1 on all other nodes.
  3. In the details pane of one node, double-click Cluster service.
  4. On the Log On tab, type the account name in This account, type the password in Password, and then confirm the password and click OK.
  5. On the Action menu, click Start.
  6. Repeat steps 2, 3, 4, and 5 on all other nodes.

Notes

  • XOX
  • XOX
  • XOX Select Show Advanced User Rights to view all the available security settings.
  • The Cluster service on all nodes must be stopped and restarted during this procedure. The Cluster service must use the same account and password at all times on all nodes within the cluster.
  • You must use Active Directory Users and Computers to view account properties if the account is in a Windows 2000 or Windows Server 2003 family domain. You must use User Manager for the Domain to view account properties if the account is in a Windows NT 4.0 domain. User Manager for the Domain can be installed using the client-based Network Administration tools by running Setup.exe from the Windows NT Server 4.0 media in the Clients\Srvtools\Winnt\ directory or by running Usrmgr.exe from the Clients\Srvtools\Winnt\I386 or Clients\Srvtools\Winnt\Alpha directory.
  • For more information on granting account rights, see Related Topics.

Related Topics


Change the Cluster service account password

Microsoft Windows graphic

To change the Cluster service account password

  1. Log on to a computer in the domain. The account you use to log in must belong to the local administrative group on all the cluster nodes.

    Important

    • To be able to change the Cluster service account password, you must have appropriate security administrative rights and permissions to be able to traverse directories in the cluster domain even if you do not have user rights on the traversed directory (Bypass traverse checking). By default, this user right is enabled for all users, but some administrators may disable it for everyone.

      For more information, see "Bypass traverse checking" in Related Topics.

    • For multiple clusters that use the same Cluster service account, it is highly recommended that you change the password for all the clusters at the same time.
    • You can only use this procedure to change the Cluster service account if applications (for example, Microsoft SQL Server 2000) do not use the same account as the Cluster service account. If you use this procedure on a server cluster where the Cluster service and one or more applications use the same account, your cluster applications may not function correctly. To resolve this problem, change the application account password (see your application's documentation for details).
  2. Open Command Prompt
  3. Type the following command, using the table below as a guide:

    cluster /cluster:cluster_name1[,cluster_name2, ...] /changepass[word][:new_password[,old_password]] [/skipdc] [/force] [/options]

    For more information on the other optional password change cluster.exe commands, see "Cluster" in Related Topics.

    Argument | Description
    /cluster:cluster_name1[,cluster_name2, ...] | Identifies the cluster(s) for the account password change. If multiple clusters are specified in one operation, they must all use the same Cluster service account. If some nodes are unavailable, the account password is not changed on any of the nodes nor on the domain controller.
    /changepass[word][:new_password[,old_password]] | Changes the Cluster service account password on the domain controller and all the cluster nodes from old_password to new_password. If not supplied as part of the command, you will be prompted to provide the new_password and/or the old_password. You can specify a blank password by supplying two double quotes ("").
    /skipdc | Changes the Cluster service account password only on the cluster nodes. You can use this command if you previously issued a cluster /changepass command for multiple clusters and the Cluster service account password was not updated on all the clusters, for whatever reason. If you use this argument, you do not have to supply the old_password parameter.
    /force Forces the execution of the password change command on the available nodes in the cluster even if some of the cluster nodes are not available.

    Important

    • Any node that is down when the password is changed will be unable to later join the cluster until the Cluster service account password for that node is updated manually using Computer Management.
    For the first example, to change the password for clusters CLUS1 and CLUS2 from B2PartTwo! to WordTestPassPartOne! on the domain controller and on all cluster nodes, type:

    cluster /cluster:CLUS1,CLUS2 /changepass:WordTestPassPartOne!, B2PartTwo!

    For the second example, if 2 of the nodes in cluster CLUS1 were down, you could force this password change on the domain controller and on all available cluster nodes in CLUS1 by typing:

    cluster /cluster:CLUS1 /changepass:WordTestPassPartOne!, B2PartTwo! /force

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    cluster /changepass /?

  • If you do not use the /force command in a cluster where some of the nodes are unavailable, the Cluster service password for any available cluster nodes or the domain controller will not be updated.
  • You cannot use this method to change the Cluster service account password if some nodes in the cluster are running Windows NT or Windows 2000, while others are running Windows Server 2003 family operating systems.

Related Topics


Give a user permissions to administer a cluster

Microsoft Windows graphic

To give a user permissions to administer a cluster

  1. Open Cluster Administrator.
  2. Select the cluster.
  3. On the File menu, click Properties.
  4. On the Security tab, give users permissions to administer the cluster.

Important

  • It is recommended that you allow only trusted personnel to administer a cluster.

Notes

  • XOX
  • XOX
  • Access to the cluster via Cluster Administrator can be granted or denied only to users in the local Administrators group on each node. Do not attempt to grant or deny access to domain users, global groups, local users, or local groups (other than the local Administrators group).
  • You can use an account that is a domain user account or a member of a global group to remotely or locally administer a cluster if you use cluster.exe or cluster scripting tools. For more information, see Cluster and the Microsoft Platform Software Development Kit (SDK).
  • The local Administrator account and local system account always have access to the cluster.

Related Topics


Move a server cluster to another domain

Microsoft Windows graphic

To move a server cluster to another domain

  1. Create a user account for the Cluster service in the new domain.

    For more information, see "To create a new user account" in Related Topics.

  2. Open Local Security Policy and grant that account the following rights:

    Where?

    • Security Settings
    • Local Policies
    • User Rights Assignments
    • Act as part of the operating system
    • Back up files and directories
    • Restore files and directories
    • Adjust memory quotas for a process
    • Log on as a service
    • Increase scheduling priority

    By default, the Cluster service account inherits the following user rights as a result of being a member of the local Administrators group:

    • Manage auditing and security log
    • Debug programs
    • Impersonate a client after authentication

    If your organization has removed these user rights from the default set of privileges assigned to the local Administrators group, you need to specifically assign these user rights to the Cluster service account.

    3. Important

    • The new Cluster service account must have administrative rights and permissions on all nodes in the cluster.
  3. Stop the Cluster service on all nodes.

    For more information, see "To stop the Cluster service" in Related Topics.

  4. Power down all nodes except one.
  5. Move the node to another domain.

    For more information, see "To join a domain" in Related Topics.

  6. Set the Cluster service to start manually.

    For more information, see "To set the Cluster service to only start manually" in Related Topics.

  7. Restart the node.
  8. On the node, change the service account used by the Cluster service to log on to the domain using the user account you just created.

    How?

    1. Open Computer Management.
    2. In the console tree, click Services.

      Where?

      • Computer Management
      • Services and Applications
      • Services
    3. In the details pane, click Cluster Service.
    4. On the Action menu, click Properties.
    5. On the Log On tab, select This account, and then supply the new account and password.
  9. Start the Cluster service.

    For more information, see "To start the Cluster service" in Related Topics.

  10. Verify that cluster node is operating correctly.

    How?

    1. Bring all resources online.

      For more information, see "To bring a resource online" in Related Topics.

    2. Ping the IP address of the cluster, the individual nodes, and any resource containing an IP address (for example, a virtual server) from all clients. That is, on each client, type the following at the command prompt:

      ping xxx.xxx.xxx.xxx

      where xxx.xxx.xxx.xxx is the IP address.

    Important

    • At this point, you can still cancel the move by moving this node back into the old domain and starting those nodes that have not yet been moved.
  11. Power up another node and repeat steps 5-10 to migrate the other nodes, one by one, to the new domain.

Caution

  • Use this procedure only if your cluster is extremely simple; otherwise recreate your existing cluster in the new domain.

Notes

  • XOX
  • XOX

Related Topics


Manage the cluster configuration and diagnostic logs

  • View the cluster configuration log
  • View the cluster diagnostic log
  • Change the size of the cluster diagnostic log


View the cluster configuration log

Microsoft Windows Graphic

To view the cluster configuration log

  1. Open Command Prompt
  2. Locate the ClCfgSrv.log file.

    By default, the log file for the New Server Cluster Wizard and the Add Nodes Wizard can be found at %systemroot%\system32\LogFiles\Cluster\ClCfgSrv.log.

  3. Use any text editor to view the log file.

Important

  • After using the New Server Cluster Wizard and the Add Nodes Wizard from a remote computer, the cluster configuration log file generated by those wizards is saved to the remote computer. This log file may contain company-sensitive data such as a complete description of the cluster configuration, including IP addresses. This information could be used by malicious users to attack the cluster; it is recommended that you restrict access to that file to cluster administrators and the Cluster service account. For more information, see Best practices for securing server clusters.

Notes

  • XOX
  • XOX
  • If you do not have administrative rights on the node on which you are using the New Server Cluster Wizard or Add Nodes Wizard, the log file will be written to the local %Temp% directory.
  • This log file contains all of the errors, warnings, and informational messages that have been generated by the New Server Cluster Wizard or the Add Nodes Wizard when creating a new cluster or when the cluster membership changes (for example, if a new node is added to the cluster).
  • You can use this log file to troubleshoot cluster setup and configuration issues. For more information about interpreting the entries in the cluster configuration log, see Q295648, "How to Analyze the Cluster Configuration Log Files" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

Related Topics


View the cluster diagnostic log

Microsoft Windows Graphic

To view the cluster diagnostic log

  1. Open Command Prompt
  2. Locate the cluster.log file.

    By default, the log file for the Cluster service can be found at %systemroot%\Cluster\cluster.log.

  3. Use any text editor to view the log file.

    For more information about interpreting the entries in the cluster log, see "Interpreting the Cluster Log" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/).

Note

  • XOX
  • XOX

Related Topics


Change the size of the cluster diagnostic log

Microsoft Windows graphic

To change the size of the cluster diagnostic log

  1. Open Control Panel.
  2. Double-click System.
  3. On the Advanced tab, click Environment Variables.
  4. Under System variables, click New.
  5. In the New System Variable dialog box, in Variable name, type ClusterlogSize, and in Variable value, type ClusterlogSize=x, where x is the size in megabytes that you want the cluster log to be.
  6. Click OK until you exit the System Properties page.
  7. Stop and restart the Cluster service. For more information on starting and stopping the Cluster service, see Related Topics.

Notes

  • XOX
  • The default diagnostic cluster log size is 8 megabytes (MB), but can be changed in the manner described previously.
  • When the cluster log file is full, the Cluster service overwrites the first half of the log with the second half. Therefore, if the cluster log size is nMB, then only (n/2)MB of that log is guaranteed to be valid.
  • You must set ClusterlogSize as a System variable, not a user variable.

Related Topics


Perform advanced administrative tasks

  • Use a different disk for the quorum resource
  • Recover from a corrupted quorum log or quorum disk
  • Migrate a multinode cluster to a single-node configuration
  • Force quorum in a majority node set server cluster
  • Enable Kerberos authentication for virtual servers


Use a different disk for the quorum resource

Microsoft Windows graphic

To use a different disk for the quorum resource

  1. Open Cluster Administrator.
  2. If one does not already exist, create a Physical Disk or other storage-class resource for the new disk.

    For more information, see "Checklist: Installing a Physical Disk resource" in Related Topics.

  3. In the console tree, click the cluster name.
  4. On the File menu, click Properties.
  5. On the Quorum tab, click Quorum resource, and then select a new disk or storage-class resource you want to use as the quorum resource for the cluster.
  6. In Partition, if the disk has more than one partition, click the partition where you want the cluster specific data kept.
  7. In Root path, type the path to the folder on the partition; for example:

    \MSCS\

Important

  • If Cluster Administrator does not open, it may be because the Cluster service is not started. To start the Cluster service, see "To set the Cluster service to only start manually" in Related Topics.
  • If the quorum resource becomes corrupted, you cannot move it until it is repaired. For more information, see "Node-to-node connectivity problems" in Related Topics.
  • If the Cluster service is stopped on any other node, or the node is shut down, that node will not be able to form a cluster. Only nodes that are online when this change is made can form the cluster. However, nodes that are offline can still join the cluster and will be able to form a cluster after they have joined the cluster at least once.

Notes

  • XOX
  • XOX
  • Of the default resource types, only the Physical Disk, Local Quorum, or Majority Node Set resource can be a quorum resource. However, third party vendors can supply other storage class resource types that are quorum capable.

Related Topics


Recover from a corrupted quorum log or quorum disk

Microsoft Windows graphic

To recover from a corrupted quorum log or quorum disk

  1. If the Cluster service is running, open Computer Management.
  2. In the console tree, double-click Services and Applications, and then click Services.
  3. In the details pane, click Cluster Service.
  4. On the Action menu, click Stop.
  5. Repeat steps 1, 2, 3, and 4 for all nodes.
  6. If you have a backup of the quorum log, restore the log by following the instructions in "Backing up and restoring server clusters" in Related Topics.
  7. If you do not have a backup, select any given node. Make sure that Cluster Service is highlighted in the details pane, and then on the Action menu, click Properties.

    8. Under Service status, in Start parameters, specify /fixquorum, and then click Start.

  8. Switch from the problematic quorum disk to another quorum resource.

    For more information, see "To use a different disk for the quorum resource" in Related Topics.

  9. In Cluster Administrator, bring the new quorum resource disk online.

    For information on how to do this, see "To bring a resource online" in Related Topics.

  10. Run Chkdsk, using the switches /f and /r, on the quorum resource disk to determine whether the disk is corrupted.

    For more information on running Chkdsk, see "Chkdsk" in Related Topics.

    If no corruption is detected on the disk, it is likely that the log was corrupted. Proceed to step 12.

  11. If corruption is detected, check the System Log in Event Viewer for possible hardware errors.

    Resolve any hardware errors before continuing.

  12. Stop the Cluster service after Chkdsk is complete, following the instructions in steps 1 - 4.
  13. Make sure that Cluster Service is highlighted in the details pane. On the Action menu, click Properties.

    Under Service status, in Start parameters, specify /resetquorumlog, and then click Start.

    This restores the quorum log from the node's local database.

    Important

    • The Cluster service must be started by clicking Start on the service control panel. You cannot click OK or Apply to commit these changes as this does not preserve the /resetquorumlog parameter.
  14. Restart the Cluster service on all other nodes.

Notes

  • XOX
  • XOX
  • The quorum disk must be formatted with the NTFS file system.
  • If none of the nodes are running, or one node fails while you are changing the quorum resource, only the running nodes are able to form the cluster, and the offline node is only able to join the cluster. After the offline node has joined the cluster, all nodes are again able to form or join the cluster. This design prevents the offline node from forming the cluster using the old quorum resource.
  • Optionally, after step 13 above, you can use the ClusterRecovery tool, available in the Microsoft Windows Server 2003 Resource Kit, to restore the registry checkpoint files.

Related Topics


Migrate a multinode cluster to a single-node configuration

Microsoft Windows graphic

To migrate a multinode cluster to a single-node configuration

  1. If your multinode cluster has been upgraded from Windows 2000 or Windows NT 4.0, open Command Prompt, and type the following to create the Local Quorum resource type:

    cluster restype "local quorum" /create /dll:clusres.dll /type:"local quorum"

    If your multinode cluster is not an upgraded cluster, skip this step.
  2. Open Cluster Administrator.
  3. Create a Local Quorum resource on the node you want to configure as the single-node cluster.

    For more information on creating a new resource, see "To create a new resource" in Related Topics.

    For more information on the Local Quorum resource type, see "Local Quorum resource type" in Related Topics.

  4. Remove all nodes from the cluster except the node you want to configure as the single-node cluster.

    For more information on removing a node, see "To evict a node from the cluster" in Related Topics.

  5. Verify that the single node now owns all resource groups by clicking on Groups in the console tree and reviewing the Owner column in the details pane.
  6. Change the quorum resource to use the Local Quorum resource.

    In the console tree, click the cluster name. On the File menu, click Properties. On the Quorum tab, click Quorum resource, and then select Local Quorum.

  7. Select the appropriate partition.
  8. Select the appropriate directory (root path). By default, the cluster database for a single-node cluster is stored at %systemroot%\Cluster\MSCS.

Important

  • If the quorum resource becomes corrupted, you cannot move it until it is repaired. For more information, see "Node-to-node connectivity problems" in Related Topics.

Notes

  • XOX
  • XOX
  • Of the default resource types, only the Physical Disk, Local Quorum, or Majority Node Set resource can be a quorum resource. However, third party vendors can supply other storage class resource types that are quorum capable.
  • For 64-bit editions of XOX or XOX, cluster disks on a shared bus must be partitioned as MBR and not as GUID partition table (GPT) disks.

Related Topics


Force quorum in a majority node set server cluster

Microsoft Windows graphic

To force quorum in a majority node set server cluster

  1. Open Cluster Administrator.
  2. Stop the Cluster service on all remaining nodes.

    For more information on stopping the Cluster service, see "To stop the Cluster service" in Related Topics.

  3. Open Registry Editor.
  4. Create a String value called ForceQuorum under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ClusSvc\Parameters subkey
  5. Set the value of ForceQuorum to a comma-separated list of the names of the nodes that are to be part of the quorum set.

    For example, if the cluster that has lost quorum contains nodes "Node5", "Node6" and "Node7", then set up the ForceQuorum registry key as "Node5,Node6,Node7".

    Caution

    • If you do not list all the nodes stopped in step 2 in the ForceQuorum key, then you must either power off the nodes not listed or physically disconnect them from the network before performing the next step.
  6. Start the Cluster service on the remaining nodes.

    For more information on starting the Cluster service, see "To start the Cluster service" in Related Topics.

Important

  • When you force quorum in a majority node set cluster, an error message from the Service Control Manager may appear, indicating that the Cluster service failed to start. You can safely ignore this message at this time; the Cluster service will continue startup after the end of the startup timeout period for Service Control Manager.
  • Do not change your cluster configuration while the cluster is operating in this interim state. For example, do not add or remove nodes, or install or modify applications running in the cluster. Changing the cluster configuration in this interim operating state may result in application data inconsistencies.

Notes

  • XOX
  • XOX

Related Topics


Enable Kerberos authentication for virtual servers

Microsoft Windows graphic

To enable Kerberos authentication for virtual servers

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder.
  3. Select the appropriate virtual server.
  4. In the details pane, click the Network Name resource for that virtual server.
  5. On the File menu, click Take Offline.
  6. On the File menu, click Properties.
  7. On the Parameters tab, select Enable Kerberos Authentication, and then click OK.
  8. In the details pane, click the Network Name resource for that virtual server.
  9. On the File menu, click Bring Online.

Notes

  • XOX
  • XOX
  • If you enable Kerberos authentication for a virtual server's Network Name resource, make sure that the Cluster service account has appropriate rights to the computer object associated with that Network Name resource. For more information, see Related Topics.

Related Topics


Manage groups

  • Create a new group
  • Delete a group
  • Bring a group online
  • Take a group offline
  • Change the properties of a group
  • Set group failover policy
  • Set group failback policy
  • Specify preferred owners of a group
  • Move a group to another node
  • Rename a group


Create a new group

Microsoft Windows graphic

To create a new group

  1. Open Cluster Administrator.
  2. On the File menu, point to New, and then click Group.
  3. In the New Group Wizard, in Name, type a name for the new group.
  4. In Description, type any comments you want, and then click Next.
  5. Under Available nodes, click the nodes you want to be the preferred owners for the group, and then click Add.

    6. You can also leave Preferred owners empty. This means that it does not matter to which node the group fails back after failover takes place. For more information, see "Failover and failback" in Related Topics.

  6. To change the priority of an owner, select the owner, click Move Up or Move Down, and then click Finish.

Notes

  • XOX
  • XOX
  • The name that you give the group is for administrative purposes only. It is not the same as a network name, which is the name that clients can use to connect to the group. However, make sure this name is different from any other group name in the cluster.
  • Cluster Administrator lists the group description and the group name in the details pane.
  • All resources within the new group fail over together. To have the group fail back to a certain node, specify that node as the preferred owner and enable failback. You can balance groups among all nodes to maximize the performance of the cluster. However, you can choose not to have a preferred owner if the location of the group does not greatly affect performance.

Related Topics


Delete a group

Microsoft Windows graphic

To delete a group

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder.
  3. In the details pane, click the group you want to remove.
  4. Delete or move all resources in the group.

    For more information on deleting or moving resources, see Related Topics.

  5. On the File menu, click Delete.

Notes

  • XOX
  • XOX

Related Topics


Bring a group online

Microsoft Windows graphic

To bring a group online

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Groups folder.
  3. In the details pane, click the group you want.
  4. On the File menu, click Bring Online.

Notes

  • XOX
  • XOX
  • Resources in a group come online in the order of their dependencies.

Related Topics


Take a group offline

Microsoft Windows graphic

To take a group offline

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Groups folder.
  3. In the details pane, click the group you want.
  4. On the File menu, click Take Offline.

Notes

  • XOX
  • XOX
  • Resources in a group go offline in the order of their dependencies.

Related Topics


Change the properties of a group

Microsoft Windows graphic

To change the properties of a group

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder.
  3. In the details pane, click the group you want.
  4. On the File menu, click Properties.
  5. Click each tab and set the various properties for the group.

Notes

  • XOX
  • XOX
  • The settings on the tabs give general information about the group and define how it performs during failover and failback.
  • Every new cluster includes at least one default group: Cluster Group. This group contains the settings for the default cluster and some typical resources that provide generic information and failover policies. Do not delete or rename the Cluster Group or move the resources in it.

    It is important to keep the Cluster Group separate. If another resource is added to this group and the resource fails, it may cause the Cluster Group to fail also, making it impossible to access the cluster using the cluster name.

    If the quorum resource is located in the Cluster Group and that resource group is moved, state change operations for other resource groups will be blocked until the Cluster Group move is completed.

    The availability of the quorum resource takes priority over failover policies set for other resources in the Cluster Group.

  • You can use the default groups as templates for creating your own groups. For example, you might add an IP Address resource, Network Name resource, and a Generic Script IIS FTP service resource to Disk Group 1, and then rename the group FTP Group.

Related Topics


Set group failover policy

Microsoft Windows graphic

To set group failover policy

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder.
  3. In the details pane, click the appropriate group.
  4. On the File menu, click Properties.
  5. On the Failover tab, type values for Threshold and Period.

Notes

  • XOX
  • XOX
  • The failover policy for a group is the maximum number of times (Threshold) that the group is allowed to fail over in the specified number of hours (Period) before it is left in a failed state. If a group fails over more often than this, the Cluster service leaves it offline. For example, if a group failover threshold is set to 5 and its failover period to 3, the Cluster service will fail over the group at most five times within a three-hour period. The sixth time a resource in the group fails, the Cluster service fails all other resources in the group and leaves the entire group offline instead of failing over the group.

Related Topics


Set group failback policy

Microsoft Windows graphic

To set group failback policy

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder.
  3. In the details pane, click the appropriate group.
  4. On the File menu, click Properties.
  5. On the Failback tab, click Prevent failback or Allow failback.

    If you click Allow failback, then either click Immediately, or click Failback between and set the time interval.

Notes

  • XOX
  • XOX
  • To set the time interval for Failback between, enter numbers between 0 and 23 for the beginning and end of the interval. If the first number is greater than the second, the interval ends on the following day. The numbers correspond to the local time of the cluster group, as read on a 24-hour clock.

    It is important to set the failback time because you may not want failback to occur during hours of peak usage.

  • If no preferred owners are specified for the group, then failback does not occur.

Related Topics


Specify preferred owners of a group

Microsoft Windows graphic

To specify preferred owners of a group

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder.
  3. In the details pane, click the appropriate group.
  4. On the File menu, click Properties.
  5. On the General tab, next to Preferred owners, click Modify.
  6. In the Modify Preferred Owners dialog box, enter any changes you want to make:
    • To add one or more preferred owners, under Available nodes, not Preferred owners, click the nodes you want to add, and then click the right arrow.
    • To remove a preferred owner, under Preferred owners, click the nodes you want to remove, and then click the left arrow.
    • To change the priority of a preferred owner, click the node, and then click the up or down arrow.

Notes

  • XOX
  • XOX
  • If more than one node is listed under Preferred owners, failover priority is determined by the order of the list. It also controls failback behavior. If failback is enabled, the group will fail back to the highest-priority node that is available. For more information, see "Determining failover policies for groups" in Related Topics.
  • If no preferred owners are specified, failback does not occur.

Related Topics


Move a group to another node

Microsoft Windows graphic

To move a group to another node

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Groups folder.
  3. In the console tree, click the group you want to move.
  4. On the File menu, click Move Group.
  5. In clusters with more than two nodes, select Best Possible or select the node to which you want to move the group.

    For more information on the logic used for the Best Possible option, see "Determining failover and move policies for groups" in Related Topics.

Notes

  • XOX
  • XOX
  • After the transfer, the new node owns all resources in the group. Verify that the Owner column in the details pane reflects this change.
  • A list of the nodes in the cluster appears only in clusters containing three or more nodes.

Related Topics


Rename a group

Microsoft Windows graphic

To rename a group

  1. Open Cluster Administrator.
  2. In the console tree, expand the Groups folder.
  3. In the details pane, click the group you want to rename.
  4. On the File menu, click Rename.
  5. In the details pane, type a new name for the group.

    This name is for administrative purposes only.

Notes

  • XOX
  • XOX
  • The group name must be different from any other group name in the cluster.


Manage resources

  • Create a new resource
  • Delete a resource
  • Bring a resource online
  • Take a resource offline
  • View or set resource properties
  • View or set resource type properties
  • Specify the restart policy for a resource
  • Modify resource dependencies
  • Specify which nodes can own a resource
  • Move a resource to another group
  • Rename a resource
  • Initiate a resource failure


Create a new resource

Microsoft Windows graphic

To create a new resource

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Groups folder.
  3. In the details pane, click the group to which you want the resource to belong.
  4. On the File menu, point to New, and then click Resource.
  5. In the New Resource Wizard, type the appropriate information in Name and Description, click the appropriate information in Resource type and Group, and then click Next.
  6. Add or remove possible owners of the resource, and then click Next.
  7. To add dependencies, under Available resources, click a resource, and then click Add.

    Or, to remove dependencies, under Resource dependencies, click a resource, and then click Remove.

  8. Repeat step 7 for any other resource dependencies, and then click Next.
  9. Set resource properties in the resource Parameters dialog box, where resource is the name of the resource type.

    Different resource types contain different configuration information in their respective dialog boxes.

    For more information on setting resource properties, see Related Topics.

Notes

  • XOX
  • XOX
  • Before adding a resource to your cluster, you must verify that the following are true:
    • The type of resource is either one of the basic types provided with the Windows Server 2003 family or a custom resource type provided by the resource vendor.
    • A group already exists within the cluster to which your resource will belong.
    • All dependent resources have been created.
  • A resource that fails frequently can affect its associated Resource Monitor and other resources interacting with that Resource Manager. For this reason, a separate Resource Monitor is recommended for any resource that has failed repeatedly in the past.

Related Topics


Delete a resource

Microsoft Windows graphic

To delete a resource

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want to remove.
  4. On the File menu, click Delete.

    5. Caution

    • When you delete a resource, Cluster Administrator also deletes all the resources that have a dependency on the deleted resource.

Notes

  • XOX
  • XOX
  • The Cluster service requires that a resource be offline before deleting it. If the resource is online, Cluster Administrator will automatically take the resource offline before deleting it.

Related Topics


Bring a resource online

Microsoft Windows graphic

To bring a resource online

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want.
  4. On the File menu, click Bring Online.

Notes

  • XOX
  • XOX
  • Bringing a resource online causes all resources on which the resource depends to be brought online.

Related Topics


Take a resource offline

Microsoft Windows graphic

To take a resource offline

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want.
  4. On the File menu, click Take Offline.

    5. Caution

    • Taking a resource offline causes all resources that depend on that resource to be taken offline.

Notes

  • XOX
  • XOX

Related Topics


View or set resource properties

Microsoft Windows graphic

To view or set resource properties

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the appropriate resource.
  4. On the File menu, click Properties.
  5. Click each tab and set the various properties for the resource.

    For more information, see "Setting resource properties" in Related Topics.

Notes

  • XOX
  • XOX

Related Topics


View or set resource type properties

Microsoft Windows graphic

To view or set resource type properties

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Cluster Configuration folder.
  3. In the console tree, click the Resource Types folder.
  4. In the details pane, click the appropriate resource type.
  5. On the File menu, click Properties, and view or set the various properties for the resource.

Notes

  • XOX
  • XOX

Related Topics


Specify the restart policy for a resource

Microsoft Windows graphic

To specify the restart policy for a resource

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want.
  4. On the File menu, click Properties.
  5. On the Advanced tab, make the changes you want.

Notes

  • XOX
  • XOX
  • The settings on the Advanced tab specify the restart policy for a resource.

Related Topics


Modify resource dependencies

Microsoft Windows graphic

To modify resource dependencies

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want.
  4. On the File menu, click Properties.
  5. On the Dependencies tab, click the resource whose dependencies you want to set, click Modify, and then make the changes you want.

Notes

  • XOX
  • XOX

Related Topics


Specify which nodes can own a resource

Microsoft Windows graphic

To specify which nodes can own a resource

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the appropriate resource.
  4. On the File menu, click Properties.
  5. On the General tab, next to Possible owners, click Modify.
  6. Specify which nodes you want to be possible owners.
    • To add a possible owner, under Available nodes, click a node, and then click the right arrow.
    • To remove a possible owner, under Possible owners, click a node, and then click the left arrow.

Notes

  • XOX
  • XOX
  • A possible owner is a node that is capable of running a resource.
  • If you want to make a group capable of failing over, it must have more than one possible owner.
  • If a resource has no possible owners, it will not come online. This can be useful if you want to keep a resource offline but you do not want to delete it and lose its configuration settings.
  • If the resource DLL for a particular resource type is not available on some nodes, these nodes are automatically removed from the possible owners list for all the resources of this type.

Related Topics


Move a resource to another group

Microsoft Windows graphic

To move a resource to another group

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want to move.

    4. Caution

    • When you move a resource to another group, all resources that depend on it or on which it depends are also moved.
  4. On the File menu, point to Change Group, and then click the name of the group to which you want to transfer ownership. Alternatively, you can select the resource you want to move, then drag and drop it to another group.

Notes

  • XOX
  • XOX

Related Topics


Rename a resource

Microsoft Windows graphic

To rename a resource

  1. Open Cluster Administrator.
  2. In the console tree, click the Resources folder.
  3. In the details pane, click the resource you want to rename.
  4. On the File menu, click Rename.
  5. Type a new name for the resource.

Notes

  • XOX
  • XOX
  • Changing the name of a resource does not affect the failover policy for that resource or for the other resources in the group to which it belongs. Also, changing the resource name does not affect the dependencies that other resources might have on the resource.
  • The resource name is only used for administrative purposes.
  • The resource name must be unique within the same cluster; other clusters may use the same resource name.

Related Topics


Initiate a resource failure

Microsoft Windows graphic

To initiate a resource failure

  1. Open Cluster Administrator.
  2. In the console tree, click the Groups folder, and then click the group that contains the resource to fail.
  3. In the details pane, click the resource you want.
  4. On the File menu, click Initiate Failure.

Notes

  • XOX
  • XOX
  • When a resource fails, it automatically restarts if a restart policy is defined for it.
  • If a resource fails repeatedly, the entire group to which the resource belongs can fail over, depending on the failover policy defined for the group.
  • This command is useful for testing the restart and failover policies of the resource and group.

Related Topics


Use Cluster Administrator

  • Connect to a cluster with Cluster Administrator
  • Change the maximum quorum-log size
  • Rename a cluster
  • Start the Cluster Application Wizard
  • Start Cluster Administrator in Microsoft Management Console


Connect to a cluster with Cluster Administrator

Microsoft Windows graphic

To connect to a cluster with Cluster Administrator

  1. Open Cluster Administrator.
  2. If you are already connected to an existing cluster, on the File menu, click Open Connection.

    If you are not connected to a cluster, the Open Connection to Cluster dialog box will appear.

  3. In Action, select Open connection to cluster. Then in Cluster or server name, type the network name or IP address of an existing cluster, or select a name from the drop-down list box, or click Browse to search for an available cluster.

Caution

  • If you use Cluster Administrator or cluster.exe to manage a server cluster, the locale settings for the user account must match the system default locale on the computer used to manage the cluster. For more information on changing the system default locale, see "To change number, currency, time, and date settings" in Related Topics.

Notes

  • XOX
  • XOX
  • When you start Cluster Administrator, connections left open when you closed the previous session are restored. If no connections were left open, Cluster Administrator prompts you to type a cluster name, a node, or an IP address before it displays any information. If you do not want to open old connections, you can start Cluster Administrator from the command line with the cluadmin /noreconnect command. For more information on administering a cluster from the command line, see "Managing a server cluster from the command line" in Related Topics.
  • You can simultaneously connect to multiple clusters, but be aware that multiple connections can affect the performance of Cluster Administrator.

    To prevent this problem, you can start a new instance of Cluster Administrator for each cluster you want to administer.

  • Use the network name or IP address of either the cluster or one of its nodes to open a connection to a cluster. If Cluster Administrator cannot find the cluster by its name, type the name of an active node in the cluster. You can also connect to the cluster by opening Cluster Administrator on a cluster node and entering a PERIOD (.) in Cluster or server name.
Related Topics


Change the maximum quorum-log size

Microsoft Windows graphic

To change the maximum quorum-log size

  1. Open Cluster Administrator.
  2. In the console tree, click the cluster.
  3. On the File menu, click Properties.
  4. Click the Quorum tab.
  5. In Reset quorum log at, type the maximum size (in increments of 64 kilobytes) that the quorum log file can be before the cluster resets it.

Notes

  • XOX
  • XOX
  • The cluster records all changes to the cluster database in the quorum log file. When the quorum log attains the specified size, the cluster saves the database and resets the log file.
  • By default, the maximum size of the quorum log is 4096 kilobytes. You may want to increase the size of the quorum log if the cluster checkpoint file stored on the quorum disk is larger than 4096 kilobytes.

Related Topics


Rename a cluster

Microsoft Windows graphic

To rename a cluster

  1. Open Cluster Administrator.
  2. In the console tree, click the cluster you want to rename.
  3. On the File menu, click Rename.
  4. Type the new name for the cluster next to its icon.

Notes

  • XOX
  • XOX
  • The cluster name cannot be the same as the computer name of a cluster node, and it cannot conflict with any other server, cluster, or domain name in use on your network.
  • The new name does not take effect until the Cluster Name resource is taken offline and brought back online. The Cluster Name resource is found in the Cluster Group resource group in a newly created cluster.
  • The cluster name can also be changed by displaying the properties of the Cluster Name resource, selecting the Parameters tab, then clicking on the Rename button.

Related Topics


Start the Cluster Application Wizard

Microsoft Windows graphic

To start the Cluster Application Wizard

  1. Open Cluster Administrator.
  2. On the File menu, click Configure Application.
  3. Follow the instructions in the wizard and provide all the information required to run the application on a server cluster, for example, the virtual server to host the application, the resource to manage your application, resource dependencies, failover and failback policies, and so on as shown in the table below.

    Information required | What it is used for
    Internet protocol (IP) address | To create a new virtual server for your application, you need an IP address. You do not need an IP address if your application runs in an existing virtual server.
    Virtual server resource group | Your clients will access your application through a virtual server: a cluster resource group with an IP address and a network name. Using the wizard, you can create a new resource group for a virtual server, use an existing resource group, or use an existing virtual server.
    Resource type for your application | You can create a resource to manage your application using the wizard. You need to know the resource type for the resource.
    Application resource name | If you use the wizard to create a resource for your application, you must name the resource.
    Application resource dependencies | If the application requires other resources to run, you can create resource dependencies using the wizard.

Notes

  • XOX
  • XOX

Related Topics


Start Cluster Administrator in Microsoft Management Console

Microsoft Windows graphic

To start Cluster Administrator in Microsoft Management Console

  1. Open Computer Management.
  2. In the console tree, double-click to expand Services and Applications.
  3. Right-click Cluster, and then click Manage.

Notes

  • XOX
  • XOX
  • Cluster Administrator is not a Microsoft Management Console (MMC) snap-in.

Related Topics


Manage networks

  • Change the name or description of a network
  • Enable a network for cluster use
  • Disable a network for cluster use
  • Change how the cluster uses a network
  • Change the description of a network interface
  • Change network priority for communication between nodes
  • Troubleshoot client-to-virtual server connectivity


Change the name or description of a network

Microsoft Windows graphic

To change the name or description of a network

  1. Open Cluster Administrator.
  2. In the console tree, double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane, click the network.
  4. On the File menu, click Properties.
  5. To change the name of the network, in Name, type a new name.
  6. To describe the network, in Description, type a new description.

Notes

  • XOX
  • XOX
  • The description provides information about the network. It appears in the details pane of Cluster Administrator when you click the Networks folder. The network description is optional.
  • When the name of a network is changed in the cluster, the name of the associated network connection is changed in the Network Connections folder on every node in the cluster.

    Also, if the name of a network connection in the Network Connections folder on any node is changed, the associated network in the cluster will also be changed, along with the network connection on all other nodes.

Related Topics


Enable a network for cluster use

Microsoft Windows graphic

To enable a network for cluster use

  1. Open Cluster Administrator.
  2. In the console tree, double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane, click the network you want to enable.
  4. On the File menu, click Properties.
  5. Select the Enable this network for cluster use check box.
  6. Specify how you want the network to be used by the cluster:
    • To use the network for communications with clients and between nodes, click All communications (mixed network).
    • To use the network only for communications between nodes, click Internal cluster communications only (private network).
    • To use the network only for communications with clients, click Client access only (public network).

Notes

  • XOX
  • XOX
  • If multiple network interfaces exist on the same subnet, only the first one can be used. Others will be ignored by the Cluster service.

Related Topics


Disable a network for cluster use

Microsoft Windows graphic

To disable a network for cluster use

  1. Open Cluster Administrator.
  2. In the console tree, double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane, click the network you want to disable.
  4. On the File menu, click Properties.
  5. Clear the Enable this network for cluster use check box.

Notes

  • XOX
  • XOX
  • After you disable a network for cluster use, the cluster cannot use the network for any communications between nodes or with clients.
  • Before you disable a network for cluster use, verify that IP address resources are not configured to use that network. If IP address resources are configured to use the network, you will be unable to clear the Enable this network for cluster use check box.

Related Topics


Change how the cluster uses a network

Microsoft Windows graphic

To change how the cluster uses a network

  1. Open Cluster Administrator.
  2. In the console tree, double-click to expand Cluster Configuration, and then click Networks.
  3. In the details pane, click the appropriate network.
  4. On the File menu, click Properties.
  5. Under Enable this network for cluster use, specify how you want the network to be used by the cluster:
    • To use the network for communication with clients and between nodes, click All communications (mixed network).
    • To use the network only for communications between nodes, click Internal cluster communications only (private network).
    • To use the network only for communications with clients, click Client access only (public network).

Notes

  • XOX
  • XOX
  • It is strongly recommended that at least two networks be configured for communication among nodes (either private or mixed). For more information, see "Best practices for configuring and operating server clusters" in Related Topics.

Related Topics


Change the description of a network interface

Microsoft Windows graphic

To change the description of a network interface

  1. Open Cluster Administrator.
  2. In the console tree, double-click to expand Cluster Configuration, and then click Network Interfaces.
  3. In the details pane, click the interface for the network on a node.
  4. On the File menu, click Properties.
  5. In Description, type information about the network interface on the node.

Notes

  • XOX
  • XOX
  • The description can provide information about the network interface on a specific node. Your information appears in the details pane when you click the Network Interfaces folder. The description is optional. However, it is strongly recommended that the network interface description reflects its role.

Related Topics


Change network priority for communication between nodes

Microsoft Windows graphic

To change network priority for communication between nodes

  1. Open Cluster Administrator.
  2. In the console tree, click the cluster.
  3. On the File menu, click Properties.
  4. Click the Network Priority tab.
  5. Under Networks used for internal cluster communications, click a network.
  6. Click Move Up to increase the network priority.

    – or –

    Click Move Down to lower the network priority.

Notes

  • XOX
  • XOX
  • If multiple networks are configured as private or mixed, you can specify which one to use for internode communication. It is recommended that private networks have higher priority than mixed networks. For more information, see Related Topics.

Related Topics


Troubleshoot client-to-virtual server connectivity

Microsoft Windows graphic

To troubleshoot client-to-virtual server connectivity

Follow the steps below to troubleshoot client-virtual server connectivity issues.
  1. Make sure the IP address and dependent Network Name resources are online.
  2. Use ipconfig /all to examine the TCP/IP configuration for all adapters. Make sure the IP address of the resource is registered to the correct adapter and that each adapter has a primary address. If the resource's IP address is not registered but the resource is online, take the resource offline and then bring it back online. If the address is still not registered with the correct adapter, consult the diagnostic cluster log.
  3. If NetBIOS has been enabled for the IP address resource, verify that the network name is properly associated with its dependent IP address resource.

    4. Use nbtstat to display the node's NetBIOS name registrations. For example, type the following at the Windows Server 2003 family command prompt:

    nbtstat -n

    The output from this command displays the IP addresses that are registered with NetBIOS. Cluster IP address resources are listed under the heading, \Device\NetBt_IF x, where x is a number. Under NetBIOS Local Name Table, you will find the NetBIOS names that are associated with the IP addresses. For each dependent network name, there are two entries: Name <20> and Name <00>, where Name is the virtual network name.

    The following is an example of this output:

    \Device\NetBt_If2:

    Node ipAddress: [172.31.248.167] Scope Id: []

    NetBIOS Local Name Table

    Name | Type | Status
CLWCLUS | <20> Unique | Registered
CLWCLUS | <00> Unique | Registered

    If the NetBIOS names are unregistered, or if there are registration conflicts, use nbtstat -rr to release the old NetBIOS names and renew their registrations. For example, type the following at the Windows Server 2003 family command prompt:

    nbtstat -rr

  4. Verify that DNS is available and functioning correctly.

    5. Use the netdiag command line tool (available in the Microsoft Windows Server 2003 Resource Kit) to evaluate the registration of DNS. For example, type the following at the Windows Server 2003 family command prompt:

    netdiag /test:DNS /d:xxx.xxx.xxx.xxx /debug

    where xxx.xxx.xxx.xxx is the IP address of the virtual server.

    If the output suggests that connectivity to the DNS server is suspect or DNS registration for the virtual name may have failed, check to see that the network connections on the virtual server are configured with the correct IP addresses of the DNS servers to be used for name resolution.

  5. Try to ping the group's IP address from all clients and cluster nodes.

    6. For example, on each client, and all cluster nodes, type the following at the Windows Server 2003 family command prompt:

    ping xxx.xxx.xxx.xxx

    where xxx.xxx.xxx.xxx is the IP address of the virtual server.

    This tests for physical connectivity between the clients and cluster node, and between the cluster nodes.

  6. Try to ping the virtual server network name from each client and cluster node.

    7. For example, at the Windows Server 2003 family command prompt on each client and on all cluster nodes, type the following:

    ping Netname

    where Netname is the network name for the virtual server.

    This test uses the appropriate name-resolution mechanism (DNS or WINS). If you can ping the IP address but ping returns unknown host when you ping the network name, then the client is unable to resolve the network name to an IP address. Check connectivity to the name server or servers by pinging their IP addresses (ipconfig all will list the addresses for each network adapter). If DNS is in use on the network but the name returned is not a fully qualified domain name (FQDN), (that is, just the NetBIOS name is returned), then connectivity to the DNS server is suspect or DNS registration for the virtual name may have failed.

  7. If the virtual server has a File Share resource, try to connect to the resource using net use.

    For example, at the Windows Server 2003 family command prompt, type the following:

    net use * \\Virtualserver\Sharename

    where Virtualserver is the network name for the virtual server and Sharename is the share name for the File Share resource.

    If you are unable to connect to the resource, you may not have the appropriate permissions set for the resource. For more information, see "Set permissions on a shared resource" in Related Topics.

  8. If clients are unable reconnect to the virtual server after a failover or move, verify that the router/switch between the client and the cluster is able to correctly handle the ARP cache flush protocol. For more information, see Related Topics.

Related Topics


Manage cluster hardware

  • Install local storage buses and devices
  • Connect the shared storage buses and assign drive letters
  • Add drives on the shared storage bus
  • Add a network adapter
  • Install an additional shared storage bus
  • Replace the redundant array of independent disks (RAID) controller
  • Configure the Always On power scheme without Terminal Services installed
  • Configure the Always On power scheme with Terminal Services installed


Install local storage buses and devices

Microsoft Windows graphic

To install local storage buses and devices

  1. Move all groups off the node on which you want to add the hardware.

    For more information, see "To move a group to another node" in Related Topics.

  2. Shut down XOX or XOX on the node to which you want to add the hardware, and then turn off the computer.
  3. Install and configure the card and devices for the new local storage bus, and then install the appropriate drivers.
  4. Turn on the computer and restart XOX or XOX on the node to which you added the hardware.
  5. If you installed a new drive, partition and format it, assigning new drive letters or mounted drives as appropriate.
  6. If you want to use Encrypted File System (EFS) on this local device, enable encryption on the device (using either the drive letter or mount point). Then, create roaming profiles for all users or service accounts that store data on that device.

    For more information, see "To encrypt a file or folder" and "To create a roaming user profile" in Related Topics.

  7. In Cluster Administrator, verify that the node has rejoined the cluster.
  8. Move the groups referenced in step 1 to the node with the new hardware, as appropriate for your cluster configuration.

Related Topics


Connect the shared storage buses and assign drive letters

Microsoft Windows graphic

To connect the shared storage buses and assign drive letters

  1. Install XOX or XOX on all nodes.

    Caution

    • All nodes in a cluster must be running the same version of the operating system, that is, either XOX or XOX. You cannot run both XOX and XOX on nodes in the same cluster.
  2. Prepare the controllers for the shared storage bus, following the instructions in your storage bus owner's manual.
  3. Install the controllers for the shared storage bus, but do not connect them to the shared storage bus.
  4. Connect the shared storage devices to the shared buses, and then connect the shared storage buses to all nodes.
  5. Start the operating system on the first node on which you intend to create the cluster.
  6. Format the disks on the cluster storage device as NTFS.

    For more information, see "To format a basic volume" in Related Topics.

    Caution

    • Each disk on the cluster storage device must be a basic disk, not a dynamic disk.
  7. Partition the disks on the cluster storage device.

    For more information, see "To create a partition or logical drive" in Related Topics.

  8. Do one of the following:
    • Assign drive letters to the disks on the cluster storage device.
    • Assign mount points to the disks on the cluster storage device.

      For more information, see "To assign, change, or remove a drive letter" and "To create a mounted drive" in Related Topics.

    Caution

    • Make sure that you create unique mounted drives so that they do not conflict with existing local drives on any node in the cluster.
    • Do not create mounted drives between disks on the cluster storage device (cluster disks) and local disks.
    • Do not create a mounted drive from a clustered disk to the cluster disk that contains the quorum resource (the quorum disk). You can, however, create a mounted drive from the quorum disk to a clustered disk.
    • Mounted drives from one cluster disk to another must be in the same cluster resource group, and must be dependent on the root disk.
  9. Label all partitions to match their drive letters or mount points assigned in the step above.
  10. Use Cluster Administrator to add the first node to the cluster.

    For more information, see "To add the first node to the cluster" in Related Topics.

    Caution

    • Completely create the cluster on one node before you join additional nodes to the cluster.

    Important

    • When you create a cluster, Physical Disk resources will be automatically created for cluster disks that use drive letters. However, if your cluster disks use mount points, Physical Disk resources will not be automatically created for those disks; you must manually create disk resources for cluster disks that use mount points. For more information on how to do this, see "Checklist: Installing a Physical Disk resource" in Related Topics.
  11. Join one or more additional nodes to the cluster.

    For more information, see "To add additional nodes to the cluster" in Related Topics.

Related Topics


Add drives on the shared storage bus

Microsoft Windows graphic

To add drives on the shared storage bus

  1. Turn off all nodes.

    2. Important

    • Unless your shared drive supports hot swapping, you must shut down and turn off all cluster nodes to add drives. If your shared drive supports hot swapping, turn off all but one node.
  2. Add or replace drives on the shared storage bus, following the manufacturer's recommendations on configuring a new drive.
  3. Turn on the first node, if it is not already on.
  4. On the first node, use Computer Management to:
    • Write a signature to the new disk.
    • Make sure the disk is a basic disk and not a dynamic disk.
    • Format the drive as NTFS.
    • Partition the drive.

      For more information, see "To create a partition or logical drive" in Related Topics.

    • Assign drive letters or mount points to the partitions on the disk that do not conflict with any other local or clustered drive letters or mount points already in use.

      For more information, see "To assign, change, or remove a drive letter" and "To create a mounted drive" in Related Topics.

    • Label each partition to match its corresponding drive letter or mount point.
  5. Create a Physical Disk or other storage-class type resource for the new disk.

    For information on how to do this, see "Checklist: Installing a Physical Disk resource", and "To create a new resource" in Related Topics.

  6. Bring the new resource online.

    For information on how to do this, see "To bring a resource online" in Related Topics.

  7. Restart all remaining nodes.
  8. Make sure the new drive is functioning correctly by placing the Physical Disk resource in a separate group and successively failing that group over to the other nodes in the cluster.

    For information on how to do this, see "To test whether group resources can fail over" in Related Topics.

Notes

  • XOX
  • On a 2-node SCSI bus, the SCSI host adapters must each have a unique SCSI ID (usually the numbers 6 and 7). In addition, the SCSI bus must be properly terminated.
  • On a Fibre Channel bus, devices can be added at any time.
  • For 64-bit editions of XOX or XOX, cluster disks on a shared bus must be partitioned as Master Boot Record (MBR) and not as GUID partition table (GPT) disks.
  • For mounted drives, do not create mount points between clustered and local disks and do not create mount points to the Quorum disk. If you assign mount points from one shared disk to another, the disks must be in the same resource group and the mounted drive must be dependent on the root disk.
  • You can enable Encrypted File System (EFS) on this cluster device and make encrypted directories accessible to clients. For more information, see "To create a cluster-managed encrypted file share" in Related Topics.

Related Topics


Add a network adapter

Microsoft Windows graphic

To add a network adapter

  1. Shut down the operating system on the node to which you want to add the hardware, and then turn off the computer.
  2. Install the adapter.
  3. Turn on the computer and restart the operating system on the node to which you added the hardware.
  4. Load the driver for the network adapter.

Note

  • Confirm that your hardware is designed for XOX or XOX by reviewing the compatibility information in Support resources.


Install an additional shared storage bus

Microsoft Windows graphic

To install an additional shared storage bus

  1. Shut down the operating system on all nodes and turn off all computers.
  2. Prepare one controller for the shared storage bus, referring to your storage bus owner's manual for instructions.

    3. Install the controllers for the shared storage bus, but do not connect them to the shared storage bus.

    For SCSI controllers, make sure that the SCSI controllers for the shared SCSI bus are using different SCSI IDs. SCSI controller IDs are preset to 7. Reset one SCSI controller ID to 6.
  3. Connect the shared storage devices to the shared bus, and then connect the shared storage bus to all nodes.
  4. Start the operating system on one node. Turn on a second node, and press F8 when the operating system Loader screen appears (not allowing the operating system to start).
  5. On the first node, use Disk Management to assign drive letters to the disks available on the new shared storage bus.

    Where?

    • Computer Management
    • Storage
    • Disk Management
  6. Make sure the Cluster service is running on this node.
  7. Create new resource groups if needed and install a Physical Disk or other storage-class type resource for each new disk.

    For more information see, "Checklist: Creating a new group", "To create a new group", "Checklist: Creating a new resource", and "To create a new resource" in Related Topics.

  8. Shut down the first node, but do not turn off the computer.
  9. On a second node, select the operating system and press ENTER.
  10. Restart the first node.

Caution

  • Do not run the operating system on all nodes at the same time until you have completed this procedure.

Related Topics


Replace the redundant array of independent disks (RAID) controller

Microsoft Windows graphic

To replace the redundant array of independent disks (RAID) controller

  • Replacing the RAID controller and updating controller configuration is hardware dependent. Refer to your hardware vendor for information on replacing your RAID controller and the effect that removal of the controller from the shared bus will have on termination.

Note

  • Replacing the RAID controller may affect the quorum disk. It is therefore advisable to back up the individual nodes and the cluster disks before replacing the RAID controller. If the quorum disk is affected, it can then be restored from the backup.

Related Topics


Configure the Always On power scheme without Terminal Services installed

Microsoft Windows graphic

To configure the Always On power scheme without Terminal Services installed

  1. Open Control Panel.
  2. Double-click Power Options.
  3. In the Power Options Properties dialog box, under Power schemes, verify that Always On is selected.
  4. Under Settings for Always On power scheme, verify that Turn off hard disks is set to Never.
  5. Verify that System standby is set to Never.
  6. Verify that System hibernates is set to Never.

Important

  • APM/ACPI Power saving features must not be enabled on server cluster members. A cluster member that turns off disk drives or enters "system standby" or "hibernate" mode can initiate a failure in the cluster. If multiple cluster nodes have power saving enabled, this can result in the entire cluster becoming unavailable.

Note

  • XOX

Related Topics


Configure the Always On power scheme with Terminal Services installed

Microsoft Windows graphic

To configure the Always On power scheme with Terminal Services installed

  1. Open Control Panel.
  2. Double-click Power Options.
  3. In the Power Options Properties dialog box, under Power schemes, verify that Always On is selected.
  4. Under Settings for Always On power scheme, verify that Turn off hard disks is set to Never.

Important

  • APM/ACPI Power saving features must not be enabled on server cluster members. A cluster member that turns off disk drives can initiate a failure in the cluster. If multiple cluster nodes have power saving enabled, this can result in the entire cluster becoming unavailable.

Notes

  • XOX

  • Installing Terminal Services on a system reduces the power management options available to the user. The System standby and System hibernates options are not available.

Related Topics


Back up and restore server clusters

  • Back up cluster disk signatures and partition layouts
  • Back up the cluster quorum
  • Back up data on cluster nodes
  • Restore the cluster database on a local node
  • Restore the contents of a cluster quorum disk for all nodes in a cluster
  • Restore a damaged cluster node using Automated System Recovery


Back up cluster disk signatures and partition layouts

Microsoft Windows graphic

To back up cluster disk signatures and partition layouts

  1. XOX

    2. The Backup or Restore Wizard starts by default, unless it is disabled.

  2. Click Advanced Mode on the Backup or Restore Wizard.
  3. On the Tools menu, click ASR Wizard.
  4. Follow the instructions that appear on your screen.

Important

  • You will need a blank 1.44 MB floppy disk to save your system settings and media to contain the backup files. If your computer does not have a floppy drive, see "Troubleshooting" in Related Topics.

Notes

  • XOX
  • By default, Backup Operators do not have the user rights necessary to create an Automated System Recovery (ASR) backup on a cluster node. However, Backup Operators can perform this procedure if that group is added to the security descriptor for the Cluster service. You can do that using Cluster Administrator or cluster.exe. For more information, see To give a user permissions to administer a cluster and Cluster.
  • Automated System Restore not only backs up cluster disk signatures and partition layouts, it also backs up the system state and other data associated with the operating system.
  • You later need to restore the signature of the quorum disk, for example, if you experience a complete system failure, and the signature of the quorum disk has changed since you last backed up, or if you experience Event ID 1034 errors when replacing a disk.

Related Topics


Back up the cluster quorum

Microsoft Windows graphic

To back up the cluster quorum

  1. Open Cluster Administrator.
  2. If you are not already connected to a cluster, connect to one.

    For more information, see "To connect to a cluster with Cluster Administrator" in Related Topics.

  3. In the console tree, click the cluster node.
  4. On the File menu, click Properties and verify that the Cluster service is running on the node on which you are performing the backup.
  5. XOX

    6. The Backup or Restore Wizard starts by default, unless it is disabled.

  6. Click Advanced Mode on the Backup or Restore Wizard.
  7. Click the Backup tab, then in Click to select the check box for any drive, folder, or file that you want to back up click the box next to System State.

    This will back up the contents of the cluster quorum along with other system state data.

    For more information, see "To back up System State data" in Related Topics.

Important

  • It is highly recommended that you perform regular backups of the cluster quorum since it contains information that is indispensible to the operation of the server cluster, for example, the current cluster configuration, application registry checkpoints, and cluster recovery log.

Notes

  • XOX
  • XOX
  • XOX
  • During backup, the following error may be displayed: "Completed with Skipped Files." This error may be ignored. The Mscs directory from the Cluster quorum drive is still successfully backed up.

Related Topics


Back up data on cluster nodes

Microsoft Windows graphic

To back up data on cluster nodes

  1. XOX

    2. The Backup or Restore Wizard starts by default, unless it is disabled.

  2. Follow the wizard instructions, selecting All information on this computer on the What to Back Up page.

    This will back up all data on the node and all the cluster disks currently owned by that node. Cluster disks not owned by that node will not be backed up.

Important

  • You will need a blank 1.44 MB floppy disk to save your system settings and media to contain the backup files. If your computer does not have a floppy drive, see "Troubleshooting the Backup Utility" in Related Topics.
  • If a cluster disk owned by the node being backed up fails over to another node during the backup process, the backup set will not contain a full backup of that disk.

Notes

  • XOX
  • XOX

Related Topics


Restore the cluster database on a local node

Microsoft Windows graphic

To restore the cluster database on a local node

  1. XOX

    2. The Backup or Restore Wizard starts by default, unless it is disabled.

  2. Click Advanced Mode on the Backup or Restore Wizard.
  3. Click the Restore and Manage Media tab, and then in Click to select the check box for any drive, folder, or file that you want to restore, click the box next to System State.
  4. Click Start Restore.

    This will stop the Cluster service on the local node and restore the cluster configuration (the cluster registry file ClusDB located in the systemroot\cluster subdirectory) for that node.

    For more information on backup and restore procedures, see "Backing up and restoring data" in Related Topics.

  5. Reboot the node when prompted.

    Rebooting the operating system replaces the cluster configuration file currently in use with the restored copy.

  6. Verify that the Cluster service restarted on the local node.

    Where?

    • Computer Management
    • Services and Applications
    • Services

Important

  • If the signature of the quorum disk has changed since you last backed up, instead of restoring the System State only, use Automated System Recovery in the Backup or Restore Wizard to restore the quorum disk signature along with the System State.

    For information on how to use Automated System Recovery, see "To recover from a system failure using Automated System Recovery" in Related Topics.

  • If you do not have a backup set available, you can manually restore the cluster database on the local node by copying the systemroot\cluster\CLUSDB file from another node. If the copy operation fails, follow the troubleshooting steps in General administrative problems.

Notes

  • You must be an administrator or a backup operator to restore System State data. For more information on permissions or user rights, see Related Topics.
  • XOX
  • You can only restore the cluster quorum disk on a local node. You cannot restore the cluster quorum disk on a remote computer.

Related Topics


Restore the contents of a cluster quorum disk for all nodes in a cluster

Microsoft Windows graphic

To restore the contents of a cluster quorum disk for all nodes in a cluster

  1. XOX

    2. The Backup or Restore Wizard starts by default, unless it is disabled.

  2. Click Advanced Mode on the Backup or Restore Wizard.
  3. Click the Restore and Manage Media tab, and then in Click to select the check box for any drive, folder, or file that you want to restore, click the box next to System State.
  4. Click Start Restore.
  5. On the Confirm Restore dialog box, click Advanced.
  6. Select Restore the Cluster Registry to the quorum disk and all other nodes, then click OK
    7. .

  7. This action will stop the Cluster service on the local node and restore the cluster configuration (the cluster registry file ClusDB located in the systemroot\cluster subdirectory) for that node.

    For more information on backup and restore procedures, see "Backing up and restoring data" in Related Topics.

  8. Reboot the node when prompted.

    This will restart the Cluster service on the local node and stop the Cluster service on all other nodes in the cluster. Backup will then copy the restored quorum data from the restarted node to the cluster quorum disk and all other nodes in the cluster.

  9. Start the Cluster service on the other nodes in the cluster.

    For more information on starting the Cluster service, see "Start the Cluster service" in Related Topics.

  10. Verify that the Cluster service restarted on all nodes.

    Where?

    • Computer Management
    • Services and Applications
    • Services

Important

  • Backup will stop the Cluster service on all other nodes of the server cluster after the node that was restored reboots. The entire server cluster will therefore be down while the restored quorum data is copied to the quorum disk and the other nodes in the cluster.

Notes

  • You must be an administrator or a backup operator to restore System State data. For more information on permissions or user rights, see Related Topics.
  • XOX

Related Topics


Restore a damaged cluster node using Automated System Recovery

Microsoft Windows graphic

To restore a damaged cluster node using Automated System Recovery

  1. Make sure you have the following on hand before you begin the recovery procedure:
    • Your previously created Automated System Recovery (ASR) floppy disk and ASR backup media. The ASR disk and media contain the backed up cluster disk signatures, partition layouts, and cluster quorum (as part of the system state).
    • Your previously created backup media containing the data on the cluster nodes.
    • The original operating system installation CD.
    • If you have a mass storage controller and you are aware that the manufacturer has supplied a separate driver file for it (different from driver files available on the Setup CD), obtain the file (on a floppy disk) before you begin this procedure.
  2. Insert the original operating system installation CD into the CD drive of the damaged cluster node.

    Important

    • If you are restoring a disk signature to a damaged cluster disk, power down all other cluster nodes except the one on which you are performing the ASR restore. This cluster node must have exclusive rights to the damaged cluster disk.
  3. Restart your computer. If you are prompted to press a key to start the computer from CD, press the appropriate key.
  4. If you have a separate driver file as described in step 1, to use the driver as part of Setup, press F6 when prompted.
  5. Press F2 when prompted during the text-only mode section of Setup. You will be prompted to insert the ASR floppy disk you have previously created.
  6. Follow the directions on the screen.
  7. If you have a separate driver file as described in step 1, press F6 (a second time) when prompted after the system reboots.
  8. Follow the directions on the screen.
  9. Once you have completed all the restore steps, the restored node can rejoin the cluster.

Notes

  • XOX
  • This procedure is useful if your cluster node is damaged because of corrupt or missing system files or Cluster registry files, hard disk failure, or changes to disk signatures due to a disk replacement (Event ID 1034 errors).

Related Topics


Test cluster failures and failover policies

  • Test group failover policy
  • Test whether group resources can fail over
  • Test private network failures
  • Test node failure


Test group failover policy

Microsoft Windows graphic

To test group failover policy

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Groups folder.
  3. In the details pane, click the group.
  4. On the File menu, click Properties.
  5. On the Failover tab, set the Threshold to 0, and then click OK.
  6. In the Cluster Administrator console tree, click the group.
  7. In the details pane, click a resource.
  8. On the File menu, click Properties.
  9. On the Advanced tab, select the Affect the group check box, if it is not already selected.
  10. On the Advanced tab, set the Threshold to 0, and then click OK.
  11. On the File menu, click Initiate Failure.

Notes

  • XOX
  • XOX

Related Topics


Test whether group resources can fail over

Microsoft Windows graphic

To test whether group resources can fail over

  1. Open Cluster Administrator.
  2. In the console tree, double-click the Groups folder.
  3. In the console tree, click a group.
  4. On the File menu, click Move Group.

    On a multinode cluster server, when using Move Group, select the node to move the group to.

    Make sure the Owner column in the details pane reflects a change of owner for all of the group's dependencies.

Notes

  • XOX
  • XOX

Related Topics


Test private network failures

Microsoft Windows graphic

To test private network failures

  1. Open Cluster Administrator.
  2. Verify that there are at least two networks set up for internal cluster communication and determine which network has the highest priority for internal cluster communications.

    For more information, see "To change network priority for communication between nodes" in Related Topics. When you follow that procedure, Cluster Administrator will only list those networks that support internal cluster communication.

  3. If there are two or more internal networks, continue to step 4, otherwise stop here and do not continue.
  4. On one node, unplug the cable for the highest priority network identified above.
  5. In the console tree, click the cluster node and verify that the state of the node is still Up (that is, actively participating in all cluster operations).

Notes

  • XOX
  • XOX

Related Topics


Test node failure

Microsoft Windows graphic

To test node failure

  • Test node failure using one of the following four methods:
    • Stop the Cluster service on the node.

      This prevents clients from accessing cluster resources through that node. In this event, all resources owned by this node fail over to other nodes in the server cluster. For more information on stopping the Cluster service, see Related Topics.

    • Turn off the power on the node.

      This tests the ability of the server cluster to fail over all the resources that were owned by the powered down node.

    • On one node, unplug the network cables for all networks enabled for intracluster communications.

      This test disables all intracluster network interfaces for the node and prevents the node from exchanging heartbeats with the Cluster Network Driver on the other active nodes. In this event, the Cluster service then initiates failover of the resources owned by the node to the other nodes in the server cluster.

Note

  • Disconnecting the SCSI or fiber cable between the host bus adapter and the cluster storage device is not a supported node failure test.

Related Topics


Concepts

This section provides general background information about server clusters:

  • Server clusters overview
  • Understanding server clusters
  • Planning your server cluster
  • Using server clusters
  • Administering server clusters
  • Resources


Server clusters overview

A server cluster is a group of independent computer systems, known as nodes, working together as a single system to ensure that critical applications and resources remain available to clients. These nodes must be running XOX or XOX. Clustering allows users and administrators to access and manage the nodes as a single system rather than as separate computers. For more information about nodes, see Nodes.

A server cluster can consist of up to eight nodes and may be configured in one of three ways: as a single node server cluster, as a single quorum device server cluster, or as a majority node set server cluster. For more information about these three server cluster models, see Choosing a cluster model.

Every node may be attached to one or more cluster storage devices. You can use a shared SCSI or Fibre Channel device for cluster storage on server clusters running XOX or XOX. For server clusters with more than two nodes, it is recommended that you use Fibre Channel hardware on the shared storage bus. For 64-bit editions of XOX or XOX, cluster disks on a shared bus must use Fibre Channel hardware.

Operating System | Number of Nodes | Allowed Cluster Storage Device
XOX or XOX | 2, 3, 4, 5, 6, 7, or 8 | SCSI, Fibre Channel (recommended for clusters with more than two nodes)
64-bit edition of XOX or XOX | 2, 3, 4, 5, 6, 7, or 8 | Fibre Channel
4-node server cluster

A server cluster runs several pieces of software that fall into two categories: the software that makes the cluster run (clustering software) and the software that you use to administer the cluster (administrative software). By default, all clustering and administration software files are automatically installed on your computer when you install any operating system in the Microsoft® Windows® Server 2003 family of products.

Important

  • Only computers running XOX or XOX can be cluster nodes.

Clustering software

The clustering software enables the nodes of a cluster to exchange specific messages that trigger the transfer of resource operations at the appropriate times. There are two main pieces of clustering software: the Resource Monitor and the Cluster service. The Resource Monitor facilitates communication between the Cluster service and application resources. The Cluster service runs on each node in the cluster and controls cluster activity, communication between cluster nodes, and failure operations. When a node or application in the cluster fails, the Cluster service responds by restarting the failed application or dispersing the work from the failed system to the remaining nodes in the cluster. For more information about this process, see Failover and failback.

For more detailed information on the components of the clustering software, see the Microsoft Windows Server 2003 Resource Kit.

Administrative software

Administrators use cluster management applications to configure, control, and monitor clusters. The Windows Server 2003 family provides Cluster Administrator for this purpose. Any computer running Microsoft Windows NT® version 4.0 Service Pack 3 or later, regardless of whether it is a cluster node, can install Cluster Administrator. By default, a copy of Cluster Administrator is automatically installed on your computer when you install XOX; XOX; or XOX. For information on remote administration, see Installing Cluster Administrator on a remote computer.

You can also create, configure, and administer clusters using the cluster command. For more information, see Administering server clusters. You can use or create custom administration tools developed using the Cluster automation interfaces. For more information on the Cluster automation interfaces, see the Microsoft Platform Software Development Kit (SDK), available separately.

Administrators organize cluster resources into functional units, called groups, and assign these groups to individual nodes. If a node fails, the Cluster service transfers the groups that were being hosted by the node to other nodes in the cluster. This transfer process is called failover. The reverse process, failback, occurs when the failed node becomes active again, and the groups that were failed over to other nodes are transferred back to the original node. For more information about resources, see Server cluster resources. For more information about groups, see Groups.


Understanding server clusters

XOX and XOX use clustering to provide high-availability application support. A server cluster is a group of independent computer systems, called nodes, working together as a single system. Server clusters allow users and administrators to access and manage the nodes as a single system rather than as separate computers.

The following sections describe how XOX and XOX use server clusters to provide high availability, easy manageability, and enhanced scalability:

  • Cluster application types
  • Server cluster components
  • Cluster objects
  • Server cluster networking


Cluster application types

Applications that run in a server cluster fall into one of four categories:

  • Cluster-unaware applications

    These types of applications do not interact with the server cluster at all but can still fail over. Failure detection is limited. The Cluster service protects these applications mainly against hardware failures.

  • Cluster-aware applications

    These types of applications are characterized by superior failure detection. The Cluster service can protect these applications not only against hardware but also against software failures.

  • Cluster management applications

    These types of applications, which include Cluster Administrator and Cluster.exe, allow administrators to manage and configure clusters. For more information, see Server cluster components.

  • Custom resource types

    Resource types provide customized cluster management and instrumentation for applications, services, and devices. For more information, see Resource types.

For more information on the concepts in this topic, see:

  • Cluster Administrator
  • Administering server clusters


Server cluster components

XOX and XOX use the server cluster components to create server clusters that provide high availability, easy manageability, and enhanced scalability. These components work together to manage the cluster objects.

Server Cluster Components

The diagram shows how the cluster components relate to three types of applications and to each other within a single cluster node.

For definitions of these application types, see Cluster application types.

For more information on cluster objects, see Cluster objects.

For more information on the individual server cluster components, see:

  • Cluster service
  • Resource Monitors
  • Resource dynamic-link libraries (DLLs)
  • Cluster Administrator
  • Cluster Automation Server
  • Cluster database
  • Network and disk drivers


Cluster service

The Cluster service manages all cluster-specific activity. The Cluster service is installed at the same time as the operating system. One instance of the Cluster service runs on every node in a cluster. The Cluster service handles the following operations:

  • Manages cluster objects and configuration
  • Manages local restart policy
  • Coordinates with other instances of the Cluster service in the cluster
  • Handles event notification
  • Facilitates communication among other software components
  • Performs failover operations

For more information on cluster objects, see Cluster objects.


Resource Monitors

A Resource Monitor is a cluster component that acts as an intermediary between the Cluster service and a resource dynamic-link library (DLL). When the Cluster service makes a request of a resource, the Resource Monitor transfers that request to the appropriate resource DLL. When a resource DLL must report status or notify the Cluster service of an event, the Resource Monitor ensures that the information is delivered successfully. Resource Monitors are passive communication layers; they do not initiate operations.

The Resource Monitor runs in a process separate from the Cluster service for the following reasons:

  • To protect the Cluster service from resource failures.
  • To allow the Resource Monitor to take action if the Cluster service fails. The Resource Monitor detects Cluster service failure and responds by taking all of the resources and groups on the affected node offline.

Every cluster node runs one or more Resource Monitors. By default, the Cluster service starts only one Resource Monitor to interact with all of the resources hosted by the node. However, this default can be overridden by an administrator using either Cluster Administrator or another management application. Assign potentially problematic resource DLLs to their own Resource Monitor to prevent faulty behavior from affecting other resources and other Resource Monitors.

  • For more information on the Cluster service, see Cluster service.
  • For more information on Cluster Administrator, see Cluster Administrator.
  • For more information on the resource DLLs, see Resource dynamic-link libraries (DLLs).


Resource dynamic-link libraries (DLLs)

Resource DLLs contain instructions that manage cluster resources of one or more types. The most important role of the resource DLL is to detect application failures.

When the Cluster service issues a request to a resource, that request is passed to the Resource Monitor. The Resource Monitor, in turn, calls an entry point function in the resource DLL responsible for the resource.

XOX and XOX define several resource types and provide resource DLLs to manage them. However, a server cluster is not limited to the resource types provided with the operating system. Developers can create their own resource DLLs to replace or augment the resource DLLs provided with the operating system. Custom resource DLLs have detailed knowledge of the resources they manage and are used by resource monitors to determine the resource state (dead/alive).


Cluster Administrator

Administrators use cluster management applications to configure, control, and monitor clusters. Cluster Administrator is one such application and exists for this purpose. On computers that are not cluster nodes, for example XOX, you install Cluster Administrator using Windows Server 2003 Administration Tools. On computers running the XOX family of products, Cluster Administrator is installed, along with the Cluster service, when you install the operating system.

Important

  • Only computers running XOX or XOX can be cluster nodes.
For more information, see Installing Cluster Administrator on a remote computer.

You use Cluster Administrator to create the cluster, join nodes to the cluster, manage cluster objects, establish groups, initiate failover, handle maintenance, and monitor cluster activity through a convenient graphical interface. Developers providing their own resource types can write an extension that enables Cluster Administrator to manage their custom types. For more information on developing extensions, see the Microsoft Platform Software Development Kit (SDK).

For more information on using Cluster Administrator to manage your server cluster, see Using Cluster Administrator.


Cluster Automation Server

The Cluster Automation Server exposes a set of Component Object Model (COM) objects to any scripting language that supports automation, such as Visual Basic or the Windows Script Host (WSH). By enabling object-oriented design and the use of high-level languages, the Cluster Automation Server simplifies the process of creating a cluster-management application.

For information on how to write scripts using the Cluster Automation Server, see the Microsoft Platform Software Development Kit (SDK). For more information on WSH, see Windows Script Host. For more information on cluster-management applications, see Cluster application types.


Cluster database

The cluster registry is stored in the cluster database on each node. By default, the cluster database for a single quorum device server cluster is located at %systemroot%\Cluster\CLUSDB; for a majority node set server cluster, the cluster database is located at %systemroot%\Cluster\MNS.%ResourceGUID%$\%ResourceGUID%$\MSCS. A copy of the cluster registry is also stored in the CHKxxx.TMP file on the quorum disk. The quorum log maintains consistency between the two versions of the cluster registry. The cluster database resides in the Windows Server 2003 family registry on each cluster node. It contains information about all physical and logical elements in a cluster, including cluster objects, their properties, and configuration data.

Important

  • Do not use the net use command to connect to the share containing the cluster database files (%systemroot%\Cluster\MNS.%ResourceGUID%$\%ResourceGUID%$\MSCS) in a majority node set server cluster. Otherwise, the Majority Node Set resource (the quorum resource) may be unable to connect to the share and may fail to come online.

Each node's Cluster service maintains a consistent, updated image of the cluster database through the following mechanisms:

  • Global updates. The Cluster service replicates changes to the cluster database uniformly across all nodes.

    • Changes to the cluster database are replicated across all nodes automatically every 4 hours and also when any of the following events occur:

    1. A resource is taken online.
    2. A resource is taken offline.
    3. The Resource Monitor detects a change to one of the registry keys.
  • Periodic checkpointing. The Cluster service on the node that owns the quorum resource regularly saves a copy of the cluster database to ensure consistency.
  • Quorum resource. The Cluster service ensures that the quorum resource's recovery log contains the most recent cluster database information. Any changes between checkpoints are logged to the quorum disk if the Cluster service fails to replicate it among all nodes. The main purpose of the quorum resource is to maintain cluster consistency.

For more information on the concepts in this topic, see:

  • Nodes
  • Cluster objects
  • Cluster service
  • Quorum resource


Network and disk drivers

Network drivers

Each node in the cluster runs an instance of the Cluster Network Driver, Clusnet.sys. The Cluster Network Driver is responsible for:

  • Providing highly available intracluster communication by monitoring and leveraging all network paths between nodes.
  • Routing messages for intracluster traffic.
  • Detecting communication failure. Each node's Cluster Network Driver exchanges periodic messages, called heartbeats, with the Cluster Network Driver on the other active nodes. If a node fails to respond to a heartbeat message, the Cluster Network Driver on the node that detects the failure notifies the Cluster service that the corresponding network interface has failed. If all other intracluster network interfaces for that node fail, the Cluster service will then initiate failover of the node. Note that failure of a node to respond to a heartbeat message can be caused by node failure, network interface failure, or network failure.

The Cluster Network Driver on each node uses the Internet Assigned Numbers Authority (IANA)-assigned port of 3343. For information on removing malicious processes bound to the cluster network ports, see General administrative problems.

Disk drivers

Each node in the cluster runs an instance of the Cluster Disk Driver, Clusdisk.sys. The Cluster Disk Driver is responsible for:

  • Maintaining exclusive ownership of cluster disks. Only the node that owns the physical disk resource can access the disk. All other nodes cannot access this disk.
  • Placing reservations on disks so that they cannot be accessed by another node. If a node owns a particular disk and that disk is online, then reservations placed by Clusdisk will prevent other nodes from accessing that disk. For disks that are offline, Clusdisk will prevent disk access by blocking I/O on the local system.


Cluster objects

Cluster objects are the physical and logical units managed by the Cluster service. For more information on Cluster service, see Cluster service. Each object is associated with:

  • One or more properties, or attributes, that define the object and its behavior within the cluster.
  • A set of cluster-control codes used to manipulate the object's properties.
  • A set of object-management functions used to manage the object through the Cluster service.

This section covers:

  • Server cluster networks
  • Network interfaces
  • Nodes
  • Resource types
  • Groups
  • Server cluster resources


Server cluster networks

A network (sometimes called an interconnect) performs one of the following roles in a cluster:

  • A private network carries internal cluster communication. The Cluster service authenticates all internal communication, but administrators who are particularly concerned about security can restrict internal communication to physically secure networks.
  • A public network provides client systems with access to cluster application services. IP Address resources are created on networks that provide clients with access to cluster services.
  • A mixed (public-and-private) network carries internal cluster communication and connects client systems to cluster application services.
  • A network that is not enabled for use by the cluster (that is, neither public nor private) carries traffic unrelated to cluster operation.

Make certain that the private network is at the top of the Network Priority list for internal node-to-node communication in the cluster. For more information, see To change network priority for communication between nodes.

Tolerating network failure

The Cluster service uses all available private and mixed networks for internal communication. Configure multiple networks as private or mixed to protect the cluster from a single network failure.

If there is only one such network available and it fails, the cluster nodes stop communicating with each other. When two nodes are unable to communicate, they are said to be partitioned. After two nodes become partitioned, the Cluster service automatically shuts down on one node to guarantee the consistency of application data and the cluster configuration. This can lead to the unavailability of all cluster resources.

For example, if each node has only one network adapter, and the network cable on one of the nodes fails, each node (because it is unable to communicate with the other) attempts to take control of the quorum resource. There is no guarantee that the node with a functioning network connection will gain control of the quorum resource. If the node with the failed network cable gains control, the entire cluster is unavailable to network clients.

However, if each node has at least two networks and both networks are configured for internal communication (for example both are mixed networks), the Cluster service can tolerate network failures. In this scenario, the Cluster service can detect a public network adapter failure and fail over all resources that depend on that adapter (through its IP address) to a node where this network is available. This is accomplished because the private network is still functioning properly. If, on the other hand, an adapter on the private network fails, the Cluster service can use the public network for internal communication. This is accomplished because the public network is mixed, allowing both internal and client traffic.

Note that there must be a unique subnet for each network in the Cluster.

Node-to-node communication

The Cluster service does not use public-only networks for internal communication, even if a public network is the only available network. For example, suppose a cluster has Network A configured as private and Network B configured as public, and Network A fails. The Cluster service does not use Network B because it is public only; thus, the nodes stop communicating and the cluster breaks apart.

For more information on the concepts in this topic, see:

  • Nodes
  • Quorum resource
  • Network state management and failure detection
  • Network communication between nodes
  • Manage networks
  • Network interfaces


Network interfaces

A network interface is a card or other network adapter that connects a computer to a network. The Cluster service keeps track of all network interfaces in a server cluster. This allows you to view the state of all cluster network interfaces from a cluster management application, such as Cluster Administrator. For more information, see Network state management and failure detection.

Windows Server 2003 family operating systems automatically detect the addition and removal of network interfaces. For more information, see Plug and Play network support.


Nodes

A server cluster node is a system that has a working installation of XOX or XOX and the Cluster service. By definition, a node is always a member of a server cluster. For more information on the Cluster service, see Cluster service.

Nodes have the following characteristics:

  • Every node is attached to one or more cluster storage devices. Each cluster storage device attaches one or more disks. The disks store all of the cluster's configuration and resource data. Each disk can be owned by only one node at any point in time, but ownership can be transferred between nodes. The result is that each node has access to all cluster configuration data.
  • Every node communicates with the other nodes in the cluster through one or more physically independent networks, known as interconnects. Network adapters, also called network interfaces, attach nodes to networks.
  • Every node in the cluster can detect another system joining or leaving the cluster.
  • Every node in the cluster can detect the resources that are running locally and the resources that are running on the other cluster nodes.
  • All nodes in the cluster are grouped under a common name, the cluster name, which is used when accessing and managing the cluster.

The following states describe a node's participation in server cluster operation:

State | Meaning
Down | The node is not actively participating in cluster operations.
Joining | The node is in the process of becoming an active participant in the cluster operations.
Paused | The node is actively participating in cluster operations but cannot take ownership of resource groups and cannot bring resources online.
Up | The node is actively participating in all cluster operations.
Unknown | The state cannot be determined.

An active node can host cluster groups. For more information about groups, see Groups.

When running Cluster Administrator for the first time on a server node, the administrator can choose whether that node forms its own cluster or joins an existing cluster. When a node is powered up, the Cluster service already installed on that node searches for other active nodes on networks enabled for internal cluster communications.

Forming a new cluster

If a cluster does not already exist, the node attempts to form its own cluster by gaining control of the quorum resource. If the node gains control of the quorum resource, the node forms its own cluster and uses the recovery logs in the quorum resource to update its cluster database. The Cluster service maintains a consistent, updated copy of the cluster database on all active nodes

For more information about the quorum resource, see Quorum resource. For more information on the cluster database, see Cluster database.

Joining an existing cluster

A node can join an existing cluster if it can communicate with another cluster node. If a cluster exists and the joining node finds an active node, it attempts to join that node's cluster. If it succeeds, the Cluster service then validates the node's name and verifies version compatibility. If the validation process succeeds, the node joins the cluster. The node updates its copy of the cluster database from that on the other active nodes.


Resource types

Cluster resources are categorized by type. The Windows Server 2003 family defines several types of resources and provides resource dynamic-link libraries (DLLs) to manage the types. Developers are encouraged to create new types to fit the specific needs of their cluster-aware applications and services. By creating a new resource type, developers can have more control over how the Cluster service manages their application or service.

For more information on the resource types provided with the operating system, see Standard resource types.

For more information on the concepts in this topic, see:

  • Server cluster resources
  • Resource dynamic-link libraries (DLLs)


Groups

A group is a collection of cluster resources with the following characteristics:

  • Groups define the units of failover. That is, when one resource in a group fails and it is necessary to move the resource to an alternate node, all of the resources in the group are moved to the alternate node. For more information, see Failover and failback.
  • A group is always owned by one node at any point in time. Likewise, a resource is always owned by a single group. These relationships ensure that all of a group's members reside on the same node.

For more information on resources or nodes, see Server cluster resources or Nodes.

Groups enable resources to be combined into larger logical units. Typically, a group is made up of related or dependent resources, such as applications and their associated peripherals and data. Indeed, groups define dependency boundaries for resources: resources cannot depend on resources in other groups. Because most application-level resources have some dependency on storage, most groups are configured around storage-class resources. A simple rule of thumb is this: If a resource uses shared storage resources, the resource belongs in the same group as that storage resource.

However, groups can also be established with resources that are unrelated and nondependent to balance the load or for administrative convenience. For more information on dependent resources, see Resource dependencies. For more information on setting resource dependencies, see To modify resource dependencies.

Every group maintains a prioritized list of the nodes that can act as its host. The preferred nodes list is generated from two sources:

  • The Cluster service produces a list of preferred nodes for a group from the list of possible owners that is maintained by the group's resources. For more information on Cluster service, see Cluster service.
  • Administrators can add nodes to the list through a cluster-management application, such as Cluster Administrator. For more information on using Cluster Administrator to specify the preferred owners of a group, see To specify preferred owners of a group.

To fully exploit the processing power of a cluster, establish at least as many groups as there are nodes in the cluster and evenly distribute these groups across the cluster.

The following topics discuss important concepts related to groups:

  • Virtual servers
  • Failover and failback


Virtual servers

To access a network application or resource in a nonclustered environment, network clients must connect to a physical server (that is, a specific computer on the network identified by a unique network name and Internet protocol (IP) address). If that server fails, access to the application or resource is impossible.

Through server clusters, XOX and XOX enable the creation of virtual servers. Unlike a physical server, a virtual server is not associated with a specific computer and can be failed over like a group. If the node hosting the virtual server fails, clients can still access its resources using the same server name.

A virtual server is a group that contains:

  • A Network Name resource.
  • An IP Address resource.
  • All other resources, including applications, to be accessed by the clients of the virtual server.
  • Other virtual servers.

For more information on groups, see Groups.

A virtual server acts like a physical server in the following ways:

  • Allows access to network resources.
  • Is published to network clients under a unique server name.
  • Is associated with a network name and an IP address.

Kerberos authentication for virtual servers

Server clusters can maintain an Active Directory computer object for virtual servers in a cluster. This allows clients accessing these virtual servers to use the security features provided by Kerberos as well as NTLM. Applications that can use Active Directory, such as Message Queuing on a virtual server, can now publish information to these computer objects.

Limitations include:

  • You cannot apply Group Policy to a virtual server or the applications running on the virtual server. That is, when a virtual computer object is part of an Organizational Unit that has an associated Group Policy object, that Group Policy is not applied to the virtual server object.
  • The Cluster service account is limited to creating a maximum of 10 virtual server computer objects in Active Directory by default. For information on overriding this default, see Granting additional permissions to the Cluster service account below.

By default, Kerberos authentication for virtual servers is not enabled. You can use Cluster Administrator or cluster.exe commands to enable this feature and to configure the Kerberos properties for the network name resource of the virtual server. For more information on configuring these Kerberos properties, see To enable Kerberos authentication for virtual servers and Cluster resource.

The Cluster service account and Active Directory access rights

By default, the Cluster service account is a member of the Authenticated Users group, and as such, will have the user right Add workstations to domain. For this user right, the default quota limitation on the number of computer accounts that can be created is 10. The value of the quota can be changed by the domain administrator.

Note

  • This quota applies to the Cluster service account and not to the individual server cluster. If the same Cluster service account is used for multiple servers clusters, then the quota applies to the total number of computer accounts in all the clusters.

The default permissions granted to the Cluster service account when the computer object is created as a result of using this Add workstations to domain user right do not allow the Cluster service account to rename or disable the virtual computer object. These operations are attempted when the name of the Network Name resource is changed or if Kerberos authentication is in the process of being disabled.

Granting additional permissions to the Cluster service account

There are a number of techniques that can be used to overcome the limitation on the number of virtual server computer objects that the Cluster service account can create. All of these techniques include granting the Cluster service account one or more permissions on objects in Active Directory. At a minimum, the Cluster service account needs to be able to:

  • Reset the password on the virtual computer object.
  • Write the DnsHostName attribute on the object.
  • Write the ServicePrincipalName attribute on the object.
  • Create Message Queuing Configuration objects if the network name resource is the dependent resource of an Message Queuing resource.

The ability to write all properties is needed if it is necessary to allow the virtual computer object to be renamed or disabled. The following table identifies the permissions needed by the Cluster service account for a virtual computer object.

Permission | Description | Reference
Add workstations to domain | This is given by default to the Cluster service account (and all domain accounts). With this access right, the Cluster service is allowed to create computer objects in Active Directory. | Add workstations to domain
Write all Properties | Allows changes to the properties of the computer objects. For example, if you need to rename the computer object, you must give the Cluster service this access right. |
Create Computer Objects | Overrides the default limit of 10 virtual server computer objects in Active Directory. | Add workstations to domain

You cannot rename the computer object for a virtual server using Active Directory tools. Instead, you must use Cluster Administrator or cluster.exe to rename the Network Name for the virtual server. The Cluster service will then automatically change the name of the computer object.

For more information on the concepts in this topic, see:

  • Server cluster resources
  • Nodes
  • Active Directory overview


Failover and failback

Failover

If an individual application in a server cluster fails (but the node does not), the Cluster service typically tries to restart the application on the same node. If that fails, it moves the application's resources and restarts them on another node of the server cluster. This process is called failover. The Cluster Administrator can use a graphical console to set various recovery policies, such as dependencies between applications, whether or not to restart an application on the same server, and whether or not to automatically rebalance, or fail back, workloads when a failed server comes back online.

The Cluster service attempts to fail over a group when:

  • The node currently hosting the group becomes inactive for any reason.
  • One of the resources within the group fails, and it is configured to affect the group. For more information on configuring the failure of a resource to affect the group, see To view or set resource properties.
  • You force failover. For more information on forcing a resource to fail over, see To initiate a resource failure.

A failover attempt consists of the following steps:

  1. The Cluster service takes all the resources in the group offline in an order determined by the group's dependency hierarchy: dependent resources first, followed by the resources on which they depend. For example, if an application depends on a Physical Disk resource, the Cluster service takes the application offline first, allowing the application to write changes to the disk before the disk is taken offline.

    2. The Cluster service takes a resource offline by invoking, through a Resource Monitor, the resource DLL that manages the resource. If the resource does not shut down within a specified time limit, the Cluster service forcibly terminates the resource. For more information on setting the time-out value for a resource, see To specify the restart policy for a resource.

  2. When all of the resources are offline, the Cluster service attempts to transfer the group to the node that is listed next on the group's list of preferred host nodes. For more information on how the Cluster service determines which node to failover or failback to, see Determining failover and move policies for groups.
  3. If the Cluster service successfully moves the group to another node, it tries to bring all of the group's resources online. Failover is complete when all of the group's resources are online on the new node.

The Cluster service continues attempting to fail over a group until it succeeds or until a defined number of attempts have been made within a given time span. A group's failover policy specifies the maximum number of failover attempts that can occur in an interval of time. If the Cluster service exceeds this limit, it concludes that the group cannot be brought online anywhere in the cluster and stops trying to fail over the group. For information on how to set group failover policy, see To set group failover policy.

Ways to control failover policy

  • Define how the Cluster service detects and responds to the failure of individual resources in the group. For more information, see Resource failure.
  • Control the order in which the Cluster service takes resources offline by establishing dependency relationships between resources. For more information, see Resource dependencies.
  • Specify time-out, failover threshold, and failover period for resources. The time-out controls how long the Cluster service waits for the resource to shut down. The failover threshold and period control how many times the Cluster service attempts to fail over a resource in a particular period of time. For more information on how to set these values, see To specify the restart policy for a resource.
  • Specify a possible owner list for resources. The possible owner list for a resource controls which cluster nodes are allowed to host the resource. For more information on how to set the possible owner list for a resource, see To specify which nodes can own a resource.

For more information on the Cluster service, see Cluster service.

Failback

When a node becomes inactive for any reason, the Cluster service fails over any groups hosted by the node. When the node becomes active again, the Cluster service can fail back the groups originally hosted by the node.

The Cluster service fails back a group using the same procedures it performs during failover. That is, the Cluster service takes all of the resources in the group offline, moves the group, and then brings all of the resources in the group online.

You can set failback to occur during a specific time period. It is important to set the failback time because you may not want failback to occur during hours of peak usage.

For more information on how to configure a group's failback policy, see To set group failback policy.


Server cluster resources

A cluster resource is any physical or logical component that has the following characteristics:

  • Can be brought online and taken offline.
  • Can be managed in a server cluster.
  • Can be hosted (owned) by only one node at a time.

To manage resources, the Cluster service communicates to a resource dynamic-link library (DLL) through a Resource Monitor. When the Cluster service makes a request of a resource, the Resource Monitor calls the appropriate entry-point function in the resource DLL to check and control the resource's state. For more information on Resource Monitor or resource DLL, see Resource Monitors or Resource DLLs.

Dependent resources

A dependent resource is one that requires another resource to operate. For example, a network name must be associated with an IP address. Because of this requirement, a Network Name resource is dependent on an IP Address resource. Dependent resources are taken offline before the resources upon which they depend are taken offline, likewise, they are brought online after the resources on which they depend are brought online. A resource can specify one or more resources on which it is dependent. Resource dependencies also determine bindings. For example, clients will be bound to the particular IP address that a Network Name resource is dependent on.

When creating resource dependencies, take into account the following: some dependencies are strictly required, while others are not required but make sense to do so. For example, a file share that is not a DFS root has no required dependencies, but if the Disk resource that holds the file share fails, the file share will be inaccessible to users. Therefore, it is logical to make the file share dependent on the Disk resource.

A resource can also specify a list of nodes on which it is able to run. Possible nodes and dependencies are important considerations when administrators organize resources into groups. For more information on preferred nodes and groups, see Groups. For more information on nodes, see Nodes.

The following topics describe important concepts related to resources:

  • Quorum resource
  • Resource failure
  • Resource dependencies
  • Cluster resource visibility


Quorum resource

In every cluster, a single resource is designated as the quorum resource. This resource maintains the configuration data necessary for recovery of the cluster. This data, in the form of recovery logs, contains details of all of the changes that have been applied to the cluster database. This provides node-independent storage for cluster configuration and state data.

Quorum resource and the cluster database

The cluster database is an integral part of the formation of a server cluster. When a node joins or forms a cluster, the Cluster service must update the node's private copy of the cluster database. When a node joins an existing cluster, the Cluster service can retrieve the data from the other active nodes. However, when a node forms a cluster, no other node is available. The Cluster service uses the quorum resource's recovery logs to update the node's cluster database. To ensure cluster unity, XOX and XOX use the quorum resource to ensure that only one set of active, communicating nodes is allowed to operate as a cluster. A node can form a cluster only if it can gain control of the quorum resource. A node can join a cluster or remain in an existing cluster only if it can communicate with the node that controls the quorum resource.

For more information on the cluster database, see Cluster database.

For more information on cluster resources, see Server cluster resources.

Scenarios

To illustrate the importance of the quorum resource, consider these situations in a simple two-node cluster:

  • Node 1 fails. Node 2 continues operating, writing changes to the cluster database. But before node 1 can be restarted, node 2 fails. When node 1 becomes active, it must update its private copy of the cluster database with the changes made by node 2. The Cluster service uses the quorum resource's recovery logs to perform the update.
  • The networks providing communication between nodes 1 and 2 fail. Each node assumes the other node has failed and attempts to continue operating as the cluster. If both could succeed, the result would be two separate clusters using the same cluster name and competing for the same resources. XOX and XOX use quorum resource ownership to prevent this problem and maintain cluster unity. In this scenario, the node that gains control of the quorum resource is allowed to form a cluster, and the other fails over its resources and becomes inactive.

The quorum resource can be any resource with the following attributes:

  • The resource must enable a single node to gain physical control of it and defend its control.
  • The resource must provide physical storage that can be accessed by any node in the cluster.
  • The resource must use the NTFS file system.

Types of quorum resources

There are two resources that come with the operating system that can act as a quorum resource for multinode clusters. They are:

  • The Physical Disk resource
  • The Majority Node Set resource

For single-node clusters, the Local Quorum resource acts as a quorum resource. However, other developers can create their own quorum resource types for any resources that meet the arbitration and storage requirements. For more information, see the Microsoft Software Development Kit (SDK).


Resource failure

The Cluster service considers a resource to be failed when the resource is not operational and cannot be restarted on the current host node. The Cluster service detects resource failure as follows:

  • At periodic intervals, the Cluster service checks to see whether the resource appears operational. It does this by periodically invoking the Resource Monitor. The Resource Monitor, in turn, relies on the resource dynamic-link library (DLL) for each resource to implement a procedure to detect whether the resource is functioning properly. The resource DLL communicates the results back through the Resource Monitor to the Cluster service. You can specify how frequently the Cluster service checks for failed resources by setting the Looks Alive and Is Alive poll intervals. The Cluster service requests a more thorough check of the resource's state at each Is Alive interval than it does at each Looks Alive interval; therefore, the Is Alive poll interval is typically longer than the Looks Alive poll interval. For more information on how to set poll intervals, see To specify the restart policy for a resource.

    • For more information on Resource Monitors, see Resource Monitors.

  • If the resource DLL reports that the resource is not operational, the Cluster service attempts to restart the resource. You can specify the number of times the Cluster service can attempt to restart a resource in a given time interval. If the Cluster service exceeds the maximum number of restart attempts within the specified time period, and the resource is still not operational, the Cluster service considers the resource to be failed. For more information, see To set group failover policy.

You can configure whether a failed resource causes the group that contains the resource to be failed over to another node. For more information, see Setting advanced resource properties.

For more information on cluster resources, see Server cluster resources.

If the failed resource is configured to cause the group that contains the resource to fail over to another node, Cluster service will attempt a failover. If the number of failover attempts exceeds the group's threshold and the resource is still in a failed state, Cluster service will attempt a restart of the resource. The restart attempt will be made after a period of time specified by the resource's Retry Period On Failure property, a property common to all resources. It first tries to restart and then to fail over a resource.

Even though the unit value of this property is in milliseconds, choose a value that is in the order of minutes. Also, choose a value that is greater or equal to the value of the resource's restart period property and enforce this rule.


Resource dependencies

A dependent resource requires, or depends on, another resource to operate. For example, if a Generic Application resource requires access to clustered physical storage, it would depend on a Physical Disk resource.

The following terms describe resources in a dependency relationship:

  • A dependent resource depends on other resources (the dependencies).
  • A dependency is a resource on which another resource depends.
  • A dependency tree is a series of dependency relationships such that resource A depends on resource B, resource B depends on resource C, and so on.

Resources in a dependency tree obey the following rules:

  • A dependent resource and all of its dependencies must be in the same group.
  • The Cluster service takes a dependent resource offline before any of its dependencies are taken offline, and brings a dependent resource online after all of its dependencies are online, as determined by the dependency hierarchy.
  • Resource dependencies determine bindings. For example, clients will be bound to the particular IP address that a Network Name resource is dependent on.

Some of the resource types provided with the operating system have required dependencies. For more information, see Setting resource dependencies.

For more information on the concepts in this topic, see:

  • Server cluster resources
  • Resource types


Cluster resource visibility

When users browse the network, they can see more resources associated with a network name than you might have intended.

This happens because the browsing the network is a two-stage process. First, you locate the computer associated with a network name. Second, you ask that computer to list all of the resources that it owns. If that computer is a cluster node that hosts multiple virtual servers, you can get unintended results. For example, suppose the node called ClusterNode hosts two virtual servers, PrintServer and FileServer. In the PrintServer resource group, you have a network printer named ClusterPrinter, and in the FileServer resource group, you have a file share named ClusterFileShare. When users browse the network, all three network names (ClusterNode, PrintServer, and FileServer) are associated with the same cluster node, and that cluster node owns two resources (ClusterPrinter and ClusterFileShare). Therefore, when users browse the network, they see ClusterPrinter and ClusterFileShare associated with all three network names.

This allows users to circumvent your intended usage of network names. In the previous example, you place PrintServer and ClusterPrinter in the same resource group because you want both the network name and the printer resource to fail over as a unit to other cluster nodes; users who connect to ClusterPrinter through the network name PrintServer can maintain the connection in the event of a failover. However, users in the previous example can connect to ClusterPrinter through the network names ClusterNode and FileServer as well. If users do this, they will lose their connection to ClusterPrinter in the event of a failover because the resource ClusterPrinter will no longer belong to the computer named by ClusterNode or FileServer.

You can minimize the potential for problems by:

  • Using cluster and node names that are easily identifiable by administrators, but not users.
  • Defining virtual server names that are easily identifiable by users.
  • Associating the virtual server names with the resources hosted by the virtual server (for example, ClusterPrintServer is a good name for a virtual server that hosts a printer named ClusterPrinter).

For more information on virtual servers, see Virtual servers.


Server cluster networking

This section covers:

  • The Cluster service and TCP/IP
  • The Cluster service and name resolution
  • Network communication between nodes


The Cluster service and TCP/IP

The Cluster service requires the TCP/IP suite for its internal and client communication.

TCP/IP is an industry-standard suite of protocols, providing communication in a heterogeneous environment. Although TCP/IP is best known for its access to the Internet and Internet resources, TCP/IP is also well suited as an enterprise networking protocol because it provides interoperability between different types of computer systems. For more information on TCP/IP, see TCP/IP.

The Cluster service and DHCP

The Windows Server 2003 family supports the use of DHCP addresses as public or private node addresses (you configure public and private node addresses through the Network Connections folder, not through cluster management software). The Cluster service uses the Plug and Play network support to handle the events that occur when a DHCP-allocated Internet protocol (IP) address changes. For more information about public and private networks, see Server cluster networks.

However, it is highly recommended that you use static IP addresses for each network adapter on each node. Using DHCP leases for node addresses has some disadvantages:

  • First, when the address lease expires for a network, the node cannot communicate over that network until it obtains a new address. This makes the node's availability dependent on the availability of the DHCP server; the node cannot communicate over the network until it obtains its address from the DHCP server.
  • Second, if an address lease expires on a network configured for public communication (communication between cluster nodes and clients), it might trigger failover for resource groups that used an IP Address resource on that network.

Caution

  • The Cluster service does not support the use of IP addresses assigned from a DHCP server for the cluster administration address (which is an IP address resource associated with the cluster name) or any other IP address resources. If possible, it is recommended that you use static IP addresses for all public and private node addresses.


The Cluster service and name resolution

Clients use name resolution services to find network resources. Clients use these same services to find resources in a server cluster. The Cluster service also uses these services when a node joins one or more other nodes to form a cluster.

In both cases, name resolution is the process of translating computer names to Internet protocol (IP) addresses. You can use the Windows Internet Name Service (WINS), the Domain Name System (DNS), or both. You can also use IP broadcast name resolution. However, because IP broadcast name resolution increases network traffic, and is ineffective in routed networks, the following sections on the Cluster service and name resolution assume you are using WINS or DNS.

The Cluster service registers a Cluster resource network name and its associated Host (A) and PTR records with a DNS server if the network adapter associated with the resource has a DNS server address specified and the DNS zone accepts dynamic updates. If the zone is also integrated with Active Directory, the zone can be configured to accept only secure updates. In a secure Active Directory–integrated zone, a Cluster resource network name has the Cluster service account associated with the Host (A) and PTR records. This registration can be deleted only by the Cluster service account or the DNS administrator. If a cluster is decommissioned but might have its name reused with a different service account, the Cluster name records must be deleted from the DNS server. If not, new records will not be registered with the DNS server and the resource will fail to go online. The Event Viewer will contain an entry indicating the resource failure along with the text "DNS operation refused" in the log entry.

For more information on resource records, see Resource records reference.

For more information on dynamic updates, see Understanding zones and zone transfer.

For more information on zones and security, see Dynamic update.

The Cluster service does not require any special configuration of either WINS or DNS. If you use WINS, all cluster network resource names that have associated IP addresses are registered with WINS.

Do not use static WINS mappings for cluster resources. If you do, the clustering software cannot update the WINS entries in the event of a failover.

For more information on static versus dynamic WINS entries, see Using static mappings.


Network communication between nodes

Communication between the nodes of a cluster enables the Cluster service to detect node failures and status changes, and to manage the cluster as a single entity. You can set up multiple networks for this node-to-node communication so as to eliminate a single point of failure.

Heartbeats

The Cluster service, running on each node of the cluster, keeps track of the current state of the nodes within a cluster and determines when a group and its resources fail over to an alternate node. This communication takes the form of messages that are sent regularly between each node's Cluster service. These messages are called heartbeats.

In addition to heartbeat traffic, some network traffic occurs whenever changes are made to the cluster. For example:

  1. During startup, node-to-node communication occurs for the purpose of synchronizing the cluster databases that reside on each node. The cluster database stores configuration information about the cluster resources.
  2. Node-to-node communication to verify node failures during cluster configuration changes.

As the number of nodes in a server cluster increases, the node-to-node communication rises significantly. In XOX or XOX, for server clusters with 3 or more nodes, multiple unicast messages for two classes of intracluster traffic are replaced by single multicast messages. This reduces the intracluster traffic, resulting in lower network bandwidth consumption and improved node performance. The configuration of the server cluster must meet the following conditions for heartbeat multicasting:

  • The number of nodes that are members of the server cluster (rather than the number of nodes that are currently up and actively participating in the cluster) must be 3 or greater.
  • All the nodes in the server cluster must be running XOX or XOX.

Important

  • Both conditions above refer to nodes configured in the cluster membership rather than nodes that are currently up and actively participating in the cluster.
  • 2-node server clusters use unicast, not multicast, messaging for all intracluster traffic.
  • If you operate a server cluster of 3 or more nodes as a mixed version cluster (that is, XOX or XOX is installed on some nodes, and Windows 2000 on others), then the cluster as a whole will send unicast, not multicast, intracluster messages.
The two kinds of intracluster traffic affected by heartbeat multicasting are:
  • Heartbeat messages sent between nodes.
  • Node-to-node communication to verify node failures during cluster configuration changes.


Planning your server cluster

This section covers the options to consider as you plan how to set up server clusters to work most efficiently in your organization:

  • Choosing a cluster model
  • Cluster deployment and operation options
  • Storage configuration options
  • Planning your networking hardware
  • Addressing risks using server clusters
  • Limitations of server clusters
  • Choosing applications to run on a server cluster
  • Determining failover and move policies for groups
  • Choosing a domain model
  • Capacity planning
  • Planning for fault-tolerant disks
  • Planning for unattended setup
  • Optimizing your clusters


Choosing a cluster model

Clusters can be categorized in three configuration models in order of increasing complexity. Each cluster model uses a different quorum resource type. This section describes each model and gives examples of the types of applications that are suited to each. The three models are:

Cluster Model | Typical Deployments | Where is the Cluster Configuration Data Maintained?
Single node cluster | Development and testing platforms. | The quorum resource maintains the definitive copy of the cluster configuration data either on a cluster storage device or locally on the single node. Uses a Local Quorum resource type.
Single quorum device cluster | Highly available applications on a cluster storage device. | The quorum resource maintains the definitive copy of the cluster configuration data on the single cluster storage device connected to all nodes. Uses a Physical Disk resource type (or other storage class resource type).
Majority node set cluster Geographically dispersed server clusters. Each node maintains its own copy of the cluster configuration data. The quorum resource ensures that the cluster configuration data is kept consistent across the nodes. Uses a Majority Node Set resource type.

Important

  • A majority node set cluster is best used in controlled, targeted scenarios, as part of a cluster solution offered by your Original Equipment Manufacturer (OEM), Independent Software Vendor (ISV), or Independent Hardware Vendor (IHV). The single quorum device server cluster, the standard cluster model available in Windows NT and Windows 2000, will still cover the vast majority of your cluster deployment needs.
  • Model 1: Single node server cluster configuration
  • Model 2: Single quorum device server cluster configuration
  • Model 3: Majority node set server cluster configuration

For information on cluster deployment options, see Cluster deployment and operation options.


Model 1: Single node server cluster configuration

Model 1 shows how you can use the virtual server concept with applications on a single node server cluster.

This cluster model does not make use of failover. It is merely a way to organize resources on a server for administrative convenience and for the convenience of your clients. The main advantage of this model is that both administrators and clients can readily see descriptively named virtual servers on the network rather than having to navigate a list of actual servers to find the file shares they need. You can also use this model to provide a platform for developing and testing cluster-aware applications.

Other advantages of this model include the following:

  • The Cluster service automatically restarts the various application and dependent resources after a computer has been restored following a resource failure. This is useful for applications that benefit from an automatic restart function but do not have their own mechanisms for accomplishing it.
  • You can cluster the single node with other nodes at a future time, and the resource groups will already be in place. After you configure failover policies for the groups, the virtual servers are ready to operate.

The following figure represents an example of a single-node cluster that does not make use of failover.

Single Node Server Cluster Configuration

For example, you can use this model to locate all the file and print resources in your organization on a single computer, establishing separate groups for each department. When clients from one department need to connect to the appropriate file or print share, they can find the share as easily as they would find an actual computer.

Note

  • Some applications, such as Microsoft SQL Server versions 6.5 and 7.0, cannot be installed on a single-node cluster.


Model 2: Single quorum device server cluster configuration

Model 2 shows how you can configure multiple nodes in a single quorum device server cluster.

In this cluster model the quorum resource maintains the cluster configuration data on a single cluster storage device. This is the traditional cluster model that was available in previous versions of Windows.

The following figure represents an example of a multinode server cluster that uses a quorum device configuration.

Single Quorum Device Server Cluster Configuration

Note

  • An inaccurate perception of this model is that the cluster storage device can be a single point of failure. This is not true, especially for clusters that use Storage Area Networks (SANs) where there are often multiple, redundant paths from the cluster nodes to the storage device. It is recommended that you implement a hardware RAID solution for your cluster storage devices to guard against disk failure.


Model 3: Majority node set server cluster configuration

Model 3 shows how you can configure multiple nodes in a majority node set server cluster.

In this cluster model, each node maintains its own copy of the cluster configuration data. The Majority Node Set resource, acting as the Quorum Resource, ensures that the cluster configuration data is kept consistent across the different nodes. The quorum traffic travels unencrypted over Server Message Block (SMB) file shares. The main advantage of this model is that cluster nodes do not have to be physically connected to one or more cluster disks.

Important

  • Use a majority node set cluster only in targeted scenarios. Do not configure your cluster as a majority node set cluster unless it is part of a cluster solution offered by your Original Equipment Manufacturer (OEM), Independent Software Vendor (ISV), or Independent Hardware Vendor (IHV). The single quorum device server cluster, the standard cluster model available in Windows NT and Windows 2000, will still cover the vast majority of your cluster deployment needs.

For detailed instructions on creating a majority node set cluster, see To create a cluster.

The following figure represents an example of a majority node set server cluster.

Majority Node Set Server Cluster Configuration

For example, in an 8-node cluster, you could use this model to physically locate 5 nodes of the server cluster in one data center (for example, in Seattle) and the other 3 nodes in another data center some distance away (for example, in Los Angeles) while still presenting a single point of access to clients.

Other advantages of this model include the following:

  • If an application inadvertently corrupts one of the local quorum disks or if you need to take a quorum disk offline for maintenance, the cluster still remains available.
  • You can create clusters without cluster disks. This configuration is useful if you need to host applications that can failover, but where there is some other, application-specific way, to replicate or mirror data between nodes. For example, this model is useful if you use database log shipping for keeping a Microsoft SQL Server database state up to date.

Number of nodes in a majority node set cluster

The main disadvantage of this model is that, for n-node clusters, if more than half the nodes fail at any one time, then the cluster itself fails. The cluster is then said to have lost quorum. This is in contrast to the n-node single quorum device server cluster model which will not fail even if only a single node remains in the cluster. The table below shows the maximum number of node failures allowed in a majority node set cluster before the cluster fails.

Number of nodes, n, in the cluster | Maximum number of node failures before the cluster loses quorum
1 | 0
2 | 0
3 | 1
4 | 1
5 | 2
6 | 2
7 | 3
8 | 3

Note

  • If the server cluster loses quorum, you can restore it by forcing the quorum. For more information, see To force quorum in a majority node set server cluster.


Cluster deployment and operation options

For the single quorum device and majority node set server cluster models, there are many ways of deploying and operating your server cluster to best match the needs of your organization. These modes of operation (specified by defining the failover policies of the server cluster) are outlined in the table below.

For more information on these different modes of operation and example scenarios, see the Windows Deployment Guide.

For more information on cluster models, see Choosing a cluster model.

Operation Mode | Description | Implementation Guide
N-node Failover Pairs In this mode of operation, each application is set to fail over only between 2 specified nodes. Limit the possible owner list for each resource group to a given pair of nodes.

For more information, see To specify which nodes can own a resource.

Hot-Standby Server
/N+I 		Hot-standby server operation mode reduces the overhead of failover pairs by consolidating the "spare" node for each pair into a single node, providing a hot-standby server that is capable of running the applications from each node pair in the event of a failure. This mode of operation is also referred to as active/passive.

For larger clusters, N+I mode provides an extension of the hot-standby server mode where N cluster nodes host applications and I cluster nodes are spare nodes.

 Use a combination of the preferred owners list and the possible owners list. Set the preferred node to the node that the application will run on by default and set the possible owners for a given resource group to the preferred node and the spare node.

For more information, see To specify preferred owners of a group and To specify which nodes can own a resource.

For N+I configurations, see article Q296799, "How to Configure Windows Clustering Groups for Hot Spare Support" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)
Failover Ring In this mode of operation, each node in the cluster runs an application instance. In the event of a failure, the application on the failed node is moved to the next node in sequence. Define the order of failover for a given resource group using the preferred owner list. Choose a node order, with the preferred node list for each group starting at a different node.

For more information, see To specify preferred owners of a group.
Random | For large clusters running multiple applications, the best policy in some cases is to allow the server cluster to choose the fail over node at random. | Do not define a preferred owners list for the resource groups. Each resource group that has an empty preferred owners list will be failed over to a random node in the cluster in the event that the node currently hosting that group fails.


Storage configuration options

You can configure your cluster storage devices in two ways when you use the cluster management tools (Cluster Administrator or cluster.exe) to create a new cluster or add nodes by selecting either the Typical (full) Configuration or Advanced (minimum) Configuration options.

Typical Configuration

The Typical Configuration option is appropriate for most installations and results in a completely configured cluster. When you choose this configuration option, the cluster configuration wizards (Add Nodes Wizard and New Server Cluster Wizard) automatically:
  • Configure all disks on the shared bus as cluster disks to be managed by the cluster.
  • Create cluster disk resources for all identified cluster disks.

Important

  • The storage validation heuristics used in the Typical Configuration option assumes that all nodes see the same target IDs and Logical Unit Numbers (LUNs). For some complicated storage devices, using the Typical Configuration option could result in an error during set up. For example, when you create the first node of the cluster, the Typical Configuration option could fail if some disks, which are not on the same storage bus as the system disk, cannot be remounted. The Typical Configuration option could also fail when nodes are added to the cluster if the target IDs and LUNs do not match on all the cluster nodes. For more information about target IDs and LUNs, see the documentation for your storage devices.

Advanced Configuration

If you do not want the cluster configuration wizards to automatically set up your cluster storage, select the Advanced Configuration option. This configuration option is appropriate for clusters that have complex storage configurations or for configurations in which you do not want the cluster to manage all of the storage.

Creating a new cluster

When you create a cluster and select this option, the New Server Cluster Wizard automatically:

  • Configures only one disk to be managed by the cluster.
  • Provides you with the option to create either a Local Quorum resource, a Physical Disk (or other storage-class type) resource, or a Majority Node Set resource as the quorum resource, and then create the quorum resource.

    • Important

    • If you do not select a quorum resource type, the local quorum resource will be selected by default; however, you will be able to later switch to another quorum resource type. A local quorum cluster can only support a single node; additional nodes cannot be joined to a local quorum cluster. For more information on the three types of quorum resources, see Choosing a cluster model.

For information on using cluster.exe to create a cluster using the Advanced Configuration option, see Cluster.

Once the initial cluster is set up, you can configure additional cluster disks using Cluster Administrator or cluster.exe.

Adding nodes to a cluster

When you add nodes to a cluster and select this option, the Add Nodes Wizard does not configure the cluster storage devices. Each device on the shared bus remains as a storage device that is local to the node. You can later use Cluster Administrator or cluster.exe to configure these local storage devices as cluster storage devices.

For more information on configuring cluster storage, see Checklist: Installing a Physical Disk resource.

Recommendations

The following table summarizes these configuration options:

Storage scenario | Configuration option | Reason
SCSI or Fiber channel | Typical Configuration | Simple configuration where the storage devices have the identical identity as seen from the Device Manager MMC snap-in on each node.
Fiber channel switched fabric with multiple switches (or other complex storage configurations) | Advanced Configuration (Add Node Wizard) | One storage unit on the fabric may have a different identity (target ID, LUN) on each node in the cluster. This configuration is illustrated in the diagram below. Switched Fibre Channel Fabric Cluster
Private storage | Advanced Configuration (New Server Cluster Wizard) | One or more of the storage devices (on a different storage bus than the system disk) will not be managed by the cluster storage.
It is important that you correctly configure the storage topology (for example, SCSI, Fibre Channel, Storage Area Networks) and the storage interconnects (for example, multiple paths) used in your server cluster. Before deploying your server cluster, contact your hardware vendors to ensure that your particular cluster storage configuration is supported at the hardware level. For descriptions of supported cluster storage topologies, best practices for deploying and managing cluster storage, and a list of cluster storage-related Knowledge Base articles, see the cluster storage information at the Microsoft Web site.(http://www.microsoft.com/)


Planning your networking hardware

Implementing the correct networking infrastructure is integral to trouble-free operation of your server cluster. This section offers the following guidelines for planning your networking hardware:

Requirements

  • Your network hardware must be selected from the Windows Catalog. For information about hardware compatibility and the Windows Catalog, see Support resources.
  • The nodes of a cluster must be connected by two or more local area networks (LANs); at least two networks are required to prevent a single point of failure. A server cluster whose nodes are connected by only one network is not a supported configuration. The adapters, cables, hubs, and switches for each network must fail independently. This usually implies that the components of any two networks must be physically independent.
  • At least two networks must be configured to handle All communications (mixed network) or Internal cluster communications only (private network). For more information, see To change how the cluster uses a network.
  • Each network connecting the nodes of a cluster must be configured as a single IP subnet. The IP subnet numbers for the networks connecting the cluster nodes must be different. If a cluster node has multiple adapters attached to the same cluster network, only one adapter will be used by the Cluster service; the others will be ignored. Multiple adapters connected on one node to the same network will not provide fault tolerance or load balancing and is not recommended.
  • Teaming network adapters on all cluster networks concurrently is not supported. At least one of the cluster networks that is enabled for internal communication between cluster nodes (typically a private network) must not be teamed. The use of teaming network adapters on other cluster networks is acceptable; however, if communication problems occur on a teamed network, Microsoft Product Support Services will require that teaming be disabled. If this action resolves the problem or issue, then you must seek further assistance from the manufacturer of the teaming solution.
  • Use a virtual LAN (VLAN) to connect the nodes of a cluster as long as all of the nodes view it as the same IP subnet. The one-way communication latency between any pair of cluster nodes on the VLAN must be less than 0.5 second. The VLAN must fail independently of all other LANs or VLANs used to connect the nodes of a cluster. Again, this usually implies that the VLAN must be constructed of components that are physically independent from other networks used in the cluster. Both the hardware and software configuration of a VLAN must be certified and listed on the Windows Catalog.

Recommendations

  • Make sure that the network adapters used in all cluster nodes are identical, that is, each is the same make, model, and firmware version.
  • Reserve one network exclusively for internal communications between nodes; that network must not be teamed.


Addressing risks using server clusters

When you configure a cluster, identify the possible failures that can interrupt access to resources. A single point of failure is any component in your environment that would block data or applications if it failed. Single points of failure can be hardware, software, or external dependencies, such as power supplied by a utility company and dedicated wide area network (WAN) lines.

In general, you provide maximum reliability when you:

  • Minimize the number of single points of failure in your environment.
  • Provide mechanisms that maintain service when a failure occurs.

With XOX and XOX, you can use server clusters and new administrative procedures to provide increased reliability. However, server clusters are not designed to protect all components of your workflow in all circumstances. For example, clusters are not an alternative to backing up data; clusters protect only availability of data, not the data itself.

The following table lists common points of failure and describes whether the point of failure can be protected, either by server clusters or by other means.

Failure point | Server cluster solution | Other solutions
Network hub | Redundant networks. For more information, see Configuring cluster network hardware. | —
Utility company power | — | Uninterruptible power supply (UPS). Put each cluster node on a separate circuit.
Server connection | Failover | —
Disk | — | Hardware RAID, to protect the data on the disk. For more information, see Hardware redundant array of independent disks (RAID).
Other server hardware, such as CPU or memory. | Failover | —
Server software, such as the operating system or specific applications. | Failover | —
Wide area network (WAN) links, such as routers and dedicated lines. | — | Redundant links over the WAN, to provide secondary access to remote connections.
Dial-up connection | — | Multiple modems.
Client computer within your organization | — | Configuring multiple clients for the same level of access. If one client fails, you still have access through other clients.
Authentication of the cluster service account | — | Redundant networks. Configure individual nodes as domain controllers.

To further increase the availability of network resources and prevent the loss of data:

  • Consider having replacement disks and controllers available at your site. Always make sure that any spare parts you keep on hand exactly match the original parts, including network and SCSI components. The cost of two spare SCSI controllers can be a small fraction of the cost of having hundreds of clients unable to use data.
  • Consider providing UPS protection for individual computers and the network itself, including hubs, bridges, and routers. Computers running XOX support UPS. Many UPS solutions provide power for 5 to 20 minutes, which is long enough for the operating system to do an orderly shutdown when power fails.


Limitations of server clusters

This topic covers important limitations of server clusters.

  • Disk configuration

    You cannot configure cluster storage devices as dynamic disks or spanned volumes (volume sets) if they will be used as cluster resources.

    Disks to be used for cluster storage must be configured as basic disks and must be formatted using the NTFS file system. XOX and XOX do not support the use of dynamic disks or the features of dynamic disks, such as spanned volumes (volume sets), for cluster storage. You cannot change an existing cluster disk, such as the quorum disk, to a dynamic disk. You can, however, use the DiskPart.exe utility to extend the volume of a basic cluster disk. for more information, see DiskPart.

    Note

    • Various third party products allow for dynamic disks in a cluster. For more information, search the Microsoft Knowledge Base (http://search.support.microsoft.com/kb/) using the keywords server cluster dynamic disks.

    You cannot use Remote Storage on the cluster storage device.

    You can enable write caching on disks on any of the products in the Windows Server 2003 family. It is highly recommended that you do not enable this feature on cluster disks; otherwise, cached data will be lost during failover.

    Disable write back cache (write through only) on an internal redundant array of independent disks (RAID) controller because the data in the cache will be lost during failover. An example of an internal controller is a Peripheral Component Interconnect (PCI) card inside the node. Enable write cache on an external RAID controller. An external RAID controller is usually inside the disk cabinet and the data in the cache will fail over.

    You cannot use software RAID. You can use hardware RAID to protect the data on your cluster disk.

    For 64-bit editions of XOX or XOX, you must partition cluster disks on the cluster storage device as MBR and not as GUID partition table (GPT) disks.

  • Network configuration

    The Cluster service functions only with IP-based protocols.

    The private and public networks must be on the same subnet.


Choosing applications to run on a server cluster

Many, but not all, applications can be adapted to run on a server cluster. Of those that can, not all need to be set up as cluster resources. This section offers guidelines for making these decisions.

Important

  • All applications running in a server cluster must be from a trusted source and all files, registry checkpoints, and other resources needed for those applications must be in a secure location. For more information, see Best practices for securing server clusters.

Three criteria determine whether an application can adapt to server clustering failover mechanisms:

  • The application must use an IP-based protocol.

    Client/server applications must use an IP-based protocol (TCP, UDP, DCOM, Named Pipes, or RPC over TCP/IP) for their network communications to run on a server cluster. Any application that uses only NetBEUI or IPX protocols cannot take advantage of cluster failover.

  • The application must be able to specify where the application data is stored.

    Any application you run on a server cluster must be able to store its data in a configurable location, that is, on the disks attached to shared buses. Some applications that cannot store their data in a configurable location can still be configured to fail over. However, in such cases access to the application data is lost at failover because the data is available only on the disk of the failed node.

  • Client applications that connect to the server application must retry and recover from temporary network failures.

    During failover, client applications will experience a temporary loss of network connectivity. If the client application is configured to recover from temporary network connection problems, it will be able to continue operating after a server failover.

Applications that can be failed over can be further divided into two groups: those that support the Cluster API and those that do not.

Applications that support the Cluster API (for example, Microsoft SQL Server 2000) are defined as cluster aware. These applications can register with the Cluster service to receive status and notification information, and they can use the Cluster API to administer clusters.

Important

  • Only Microsoft SQL Server 2000 Failover Clusters and subsequent versions are supported in a server cluster running XOX or XOX.

Applications that do not support the Cluster API are defined as cluster unaware. If cluster-unaware applications meet the TCP/IP and remote storage criteria, they can still be used in a cluster and often can be configured to fail over.

In either case, applications that keep significant state information in memory are not the best applications for clustering because information that is not stored on disk is lost at failover.

Finally, it is important to note that in order for an application to be certified by Microsoft as cluster compliant, the application must meet certain requirements. Those requirements are as follows:

Summary of Cluster service requirements

Summary of Cluster service requirements

Note

  • Applications that do not meet these requirements are eligible for the XOX certification only.

Rationale

A server cluster is a group of independent servers managed as a single system for higher availability. Cluster service is a set of system services in XOX and XOX that enable you to form server clusters by connecting multiple servers together, making them appear to network clients as a single, highly available system.

Cluster service can automatically detect the failure of an application or server, and restart the application, either on the same server if it is still alive, or on another surviving server.

These requirements help ensure that your application will run properly with Cluster service enabled, so that:

  • Your server application can fail over to other servers.
  • The client side of your application properly handles failure of the server application.

Customer benefits

Customers who run your application in a clustered environment can achieve higher availability because your application can continue to provide service during both planned downtime (such as hardware and software upgrades) and unplanned outages (such as hardware or software failure).

When one of the systems, or nodes, in the cluster fails or becomes unavailable, Cluster service transfers its workload to another system in the cluster. Users experience only a momentary pause in service. You can also configure Cluster service to provide failback so that when the failed server comes back online, the workload is rebalanced across the server cluster.

Requirements

  • Applications must be able to be installed on up to eight nodes for certification on XOX or XOX.
  • Applications must support failover to all cluster members.
  • Clients must survive failure of the server application without failing or affecting the stability of the system.

How to comply with Cluster service requirements

  • Applications must be able to be installed on up to eight nodes for certification on XOX or XOX.

    Note

    • Make certain your application setup does not make any assumptions about the number of nodes in the cluster. Verify that it enumerates all nodes in the cluster and allows installing your application on any node, even if the disks where your application data is stored are not physically located on that node.
  • Applications must support failover to all cluster nodes.

    When a node in the cluster fails, Cluster service will move the resource group from that node to a new node. A resource group is a collection of resources that provide services to clients and can depend on each other.

    Resources that represent the primary functionality of your application must be able to start up (come online) on any other node in the cluster. After a failover is complete, very that clients are able to access all data exposed by primary functions.

    Note

    • Cluster service operates under a "shared nothing" architecture in which each server owns its own disk resources. In the event of a server failure, ownership of the clustered disk is transferred from one server to another. For applications to properly support failover, the application's data must be stored on the clustered disk.
  • Clients must survive failure of the server application without failing or affecting the stability of the system.

    • Any client that ships with your server application must gracefully handle both cluster node failures and application failures. Cluster and application failures may cause clients to temporarily lose their connection to the server application (see the next item). Your client must survive both the failure of the server application and node failure as follows:

    • When a connection to the server application is lost, your client application must not stop responding or compromise the stability of the client operating system.
    • After the failover is complete and the application is restarted on a cluster node, your client must reconnect to the cluster in one of the following ways:
      • Reestablish the lost connection without user intervention and with no loss of data

        --or--

      • Offer the user a chance to reconnect and retry the operation that failed; for example, prompt the user to refresh the data in the client
    • If the server application is not able to restart, the client must inform the user that the connection could not be reestablished.

Connections to the server application can be lost for any of the following reasons:

  • The application fails and is then restarted on the same node.
  • The application fails and is restarted on a new node.
  • The node fails, and all resources fail over to a new node.
  • The administrator moves the resource group containing the application to a new node.
  • The administrator shuts down the server application.
  • All nodes in the cluster fail.
  • The client's network connection to the cluster is interrupted, even though the cluster and the server application are still running.

These failures might be exposed to the client application as application time-outs, invalid handles, network failures, and connection time-outs.

Development guidelines

The guidelines in this section are not requirements that will be tested individually for certification. However, following these guidelines will help you meet the requirements described previously:

  • Use TCP/IP protocol

    Services that communicate with clients (as well as their clients) must use TCP/IP to be able to take advantage of IP address failover provided by Cluster service. Servers that do not communicate with clients do not need to use TCP/IP.

  • Make sure that applications use a virtual server name and IP address to connect to the node hosting the server application.

    Clients communicating with the cluster resources must use the virtual server IP address or virtual server network name to support failover.

    If the server application publishes a network name or IP address to clients, it must publish an IP virtual server IP address or network name. A server application that depends on a computer name or an IP address is supposed to use a network name or an IP address of a virtual server that is used by clients to access this application. Make sure that your server application does not fail to restart on another node because the computer name on this node is different.

    The following code example illustrates how to set the server application environment as part of your resource DLL online routine.

    //
// Create the new environment with the simulated net name when the
// services queries GetComputerName.
//
if ( ! ClusWorkerCheckTerminate( pWorker ) )
{
    nStatus = ResUtilSetResourceServiceEnvironment(
        YOUR_SERVICE_NAME,
        pResourceEntry->hResource,
        g_pfnLogEvent,
        pResourceEntry->hResourceHandle
        );
    if ( nStatus != ERROR_SUCCESS )
    {
        break;
    } // if: error setting the environment for the service
}

    About IP address failover

    Client applications use a virtual server IP address to access services running on a Server Cluster. A virtual server is a cluster resource group containing an IP address and a network name. A virtual server can be brought online on any node in the cluster. However, it appears to clients accessing it as the same physical computer.

    The IP address of the virtual server has to be configured as a cluster resource in the same resource group where the server application was created. In case of a node failure, all resource groups running on this node are moved to another node in the cluster. The IP address of the virtual server is now available on another node and all connections with the clients can be reestablished.

  • Upon failure, clients must preserve user data.

    The client application must be able to reconnect and resume an operation in the event of cluster node failure. It must either offer the user a chance to retry the connection, or it must retry the connection automatically until it succeeds or can determine that the server application could not be brought online.

    In case of a node failure, all resource groups running on the failed node are moved to another node in the cluster. Cluster service requires some time to bring all resources online and restart services on the other node. The time needed to fail over a server application depends on many factors. The most significant is the time required to restart the application.

  • The location of application data must be configurable.

    Cluster service can fail over only disks managed by the cluster that are on the storage bus shared among all nodes in the cluster. Make sure that your application setup allows for selecting the drive and installing application data on any drive. Cluster-aware setup should allow installing the application data only on a shared drive managed by the cluster.

  • Checkpoint either automatically or manually the state information required for a clean restart.

    If a server application maintains any state information required for a clean restart, make sure that it checkpoints this state information frequently to a cluster disk managed by a cluster. It is supposed to use this data to recover quickly after a failure.

  • Upon failure, an application can be restarted and, if applicable, recover to the last checkpoint.

    The server application must recover from a node failure. Make sure that a sudden node failure (for example, a power blackout) will not leave your application in a state in which it cannot restart.

    After a node failure, Cluster service moves the server application running on the node to another node along with any other resources it may depend on. The server application must restart, recover, and resume operation in the time you specified in your product literature.

  • At least one instance of the application can run as a cluster resource.

    Cluster service manages applications as cluster resources. A cluster resource is a physical or logical entity that can be owned by a node, brought online and taken offline, moved between nodes, and managed as a server cluster object. A resource can be owned only by a single node at any point in time. A resource is associated with, and managed by, a resource type.

    If the resource supports it, Cluster service can manage multiple instances of the same resource, but it is acceptable to support only one instance.

    To take advantage of clustering, your application has to be configured as a cluster resource. Make sure you can create at least one instance of your application. Your application must function properly as a cluster resource. Cluster service must be used to start your application (bring it online) and stop it (take it offline).

  • Can be configured at least as a generic service or application.

    The monitoring and failover capabilities of Cluster service can be extended to support any application. Cluster service uses resource DLLs to extend its failover support to other resource types.

    Applications that do not offer an application-specific resource DLL can still take advantage of clustering by using a generic application or generic service resource type. These resource types offer failover protection against most failures, notably node failure. However, they cannot detect your application failures. If your application stops responding, Cluster service will not be able to detect this failure and either restart or fail over your application.

    It is acceptable to use a generic application or a generic service type to manage your application as a cluster resource.

How to pretest applications for Cluster service requirements

How to pretest whether your application is cluster ready.

If your application's setup is cluster aware, use setup to configure all nodes.

If your application's setup is not cluster aware, install your server application on at least two nodes in the cluster. Use the Cluster Administrator console to create a virtual server and configure your server application as a generic service or application. Use the Cluster Administrator console to move your resource to either node in the cluster. If your application is cluster-ready, it is supposed to come online on any node in the cluster. Clients should be able to access the service provided by your application no matter which node hosts it.

For certification on XOX or XOX, repeat this procedure for three-node, four-node, five-node, six-node, seven-node, and eight-node configurations.

How to pretest whether your application supports failover

  1. After you have installed the application on all nodes in the cluster, run functionality tests to verify that the application is fully functional and stable.
  2. Cause the node running your application to fail so that failover of the application is triggered.

    Following are suggestions for triggering failure:

    • Hardware failure. Simulate by doing a hard reset.
    • Operating system failure. Simulate by emitting a CTRL+C command followed by a ".reboot" command from a remote kernel debugger.
    • Application failure. Simulate using the End Process feature in Task Manager or Process Viewer (Pview.exe in the Platform SDK).

    Note that normal shutdown of the computer is not a valid test for failover because the application will have the opportunity to shut down gracefully.

  3. Verify that the application restarts on a new node in the cluster.
  4. Run functionality tests to verify that all functionality is again available on the new node. The application must have access to all data to which it previously had access.
  5. For testing on XOX or XOX, repeat steps 2 through 4 to verify that the application subsequently fails over to each of the remaining nodes.

How to pretest whether clients you provide survive failure and subsequent restart of the server application

Cause the server application to fail using each of the following scenarios:

  • Shut down the server application using the normal shutdown sequence and leave all nodes in the cluster running.
  • Terminate the application process (do not use the normal shutdown sequence), but leave the node running.
  • Stop the node.

    Do not use normal shutdown. The node and application must not have time to exit gracefully. Following are suggestions for various failure modes:

    • Hardware failure. Simulate by doing a hard reset.
    • Operating system failure. Simulate by emitting a CTRL+C command followed by a ".reboot" command from a remote kernel debugger.
    • Application failure. Simulate using the End Process feature in Task Manager or Process Viewer (Pview.exe in the Platform SDK).

For each case:

  • Verify that the client does not stop responding or lose stability when the server application fails.
  • After the server application is restarted, either on the same node or a different node, verify that the client either:
    • Reestablishes the connection with no user intervention and no loss of user data.

      --or--

    • Prompts the user to retry the connection and the application then establishes the connection.

Note

  • If you need to manually configure the client to access the server application, configure it to use the virtual server, not the node name.

How to pretest whether clients you provide survive failure without subsequent restart of the server application

  • Cause the application to fail in a way that does not allow it to restart on the cluster. To do this, you can take the resource offline, or stop all nodes.
  • Verify that the clients do not stop responding or lose stability.
  • Verify that the clients notify the user in a reasonable time that the connection to the server application was lost.
  • Verify that the client can be closed without failing or affecting the stability of the client's workstation, and that the user can preserve data, if appropriate.


Determining failover and move policies for groups

For every resource group, the Cluster service maintains a prioritized list of the nodes that are supposed to act as its host. To fully exploit the processing power of a cluster, it is recommended that you understand how the Cluster service uses this prioritized list to move, failover, and failback resource groups. This will allow you to better balance groups among all nodes and maximize the performance of your server cluster.

Failover policies

You can assign the failover policies for each group of resources in your cluster. These policies determine exactly how a group behaves when failover occurs. You can choose which policies are most appropriate for each resource group you set up. For more information on setting failover policies, see Setting group properties.

Failover policies for groups include three settings:

Failover timing

You can set a group for immediate failover when a resource fails, or you can instruct the Cluster service to try to restart the failed resource a number of times before failover occurs. If it is possible that the resource failure can be overcome by restarting all resources within the group, then set the Cluster service to restart the group.

Verify that the failover threshold does not exceed the number of nodes in the cluster. For example, if the cluster contains three nodes, set the failover threshold to three.

Preferred nodes list

The Cluster service maintains an ordered, internal list of available nodes for resource group moves, failovers, and failbacks. Optionally, you can set up a prioritized list of nodes that are preferred owners for a group so that the Cluster service can choose the best available node on that list rather than choose a node at random. This list, known as the preferred nodes list, is useful if one or more of the nodes is better equipped to host the group.

Important

  • When setting up a preferred nodes list for a resource group, it is highly recommended that you define a complete preferred nodes list, that is, one listing all nodes in your server cluster, in order of priority.

Failback timing

You can set a group to fail back to its preferred node as soon as the Cluster service detects that the failed node has been restored, or you can instruct the Cluster service to wait until a specified hour of the day, such as after peak business hours.

Important

  • Failback only occurs when you have defined a preferred nodes list for a resource group and failback is allowed for that resource group.
  • If you specify that a group failback to a preferred node and then restart the node to test the failback policy you set, the resource group will not failback. A resource group will not failback when a node is restarted after a planned shutdown and restart. To test the failback policy, you must press the reset button on the node. For more information on testing failback policies, see To test node failure.

Moving groups

You can use Cluster Administrator or cluster.exe to manually move a resource group from one node to another. If you specify the destination node for the move, the Cluster service will move the group to the node you specify. However, if you do not specify the destination node, but instead select the Best Possible option, the Cluster service will select a destination node. The logic that the Cluster service uses to select the destination node will be different for each of these scenarios:
  • You have specified a list of nodes as preferred owners for that resource group.
  • You have not specified a list of nodes as preferred owners for that resource group.

For more information on moving resource groups, see To move a group to another node.

The table below summarizes the move, failover, and failback logic that the Cluster service uses depending on whether the user defines a preferred nodes list.

Scenario | Move group | Resource or node failures | Failback enabled
Preferred Nodes List Defined | Fails over to the first node on the list that is available. | Fails over to the next node on the list. | Fails back to the original node.
Preferred Nodes List Not Defined | Fails over to a randomly selected node. | Fails over to a randomly selected node. | No failback.

The section below provides details on the logic behind manual moves, failovers, and failbacks.

Moves, failovers, and failbacks

Preferred nodes list not defined

If you have not set up a preferred owners list for a group, the Cluster service creates an internal list of nodes ordered by their node IDs. In general, this is the same as the order in which the nodes were added to the server cluster. It may, however, be ordered differently if nodes have been evicted from the server cluster. When a resource group or node fails and you have not defined a preferred list of owners for that group, the Cluster service randomly selects a node from the internal list of nodes and attempts to transfer the group to that node.

If you manually move a resource group off a node without specifying a destination node, the Cluster service transfers the group to a randomly selected node.

Preferred nodes list defined

If you define a complete preferred nodes list for a group (that is, one listing all the nodes in the cluster), then the Cluster service uses this defined list as its internal list. However, if you define a partial preferred nodes list for a group, then the Cluster service uses this defined list as its internal list and appends any other installed nodes not on the preferred list, ordered by their node IDs. For example, if you created a 5-node cluster (installing the nodes in the order Node1, Node2, Node3, Node4, and Node5) and defined Node3, Node4, and Node5 as preferred owners for the resource group, PRINTGR1, the Cluster service would maintain this ordered list for PRINTGR1: Node3, Node4, Node5, Node1, Node2. How the Cluster service uses this list depends on whether the resource group move is due to a resource/node failure or a manual move group request.

Important

  • When setting up a preferred nodes list for a resource group, it is recommended that you define a complete preferred nodes list, that is, one listing all nodes in your server cluster, in order of priority.

Preferred lists and resource or node failures

For resource group or node failures, the group fails over to the node next to the current owner on the preferred nodes list. In the example above, if the resource group PRINTGR1 on Node3 fails, then the Cluster service would fail that group over to the next node on the list, Node4. If you allow failback for that group, then when Node3 comes up again, the Cluster service will fail back PRINTGR1 to that node.

Preferred lists and manual moves

If you manually move a resource group without specifying a destination node, the Cluster service fails over that group to the first node listed on the preferred nodes list that is available.


Choosing a domain model

Nodes in a server cluster can be either member servers or domain controllers. However, in either case, all nodes must belong to the same domain.

If you configure your cluster nodes as domain controllers, you must first make sure you have the hardware to support them. For more information, see Capacity planning.

If you configure all of the cluster nodes as member servers, then the availability of the cluster will depend on the availability of the domain controller. The Cluster service requires that the nodes be able to contact the domain controller to function correctly, so the domain controller must be highly available. To avoid a single point of failure, the domain must have at least two domain controllers. For more information on increasing availability, see Addressing risks using server clusters.

At least two domain controllers must be configured to be global catalog servers.

DNS considerations

If DNS is used to resolve names in the domain, then you must deploy at least two Domain Name System (DNS) servers. If your cluster nodes are the only domain controllers in their domain, they must be configured as Domain Name System (DNS) servers. Make sure that the DNS servers support dynamic updates. For more information on DNS, see DNS.

Each domain controller and cluster node must be configured with a primary and at least one secondary DNS server. If the domain controllers are also DNS Servers, then make sure each points to itself for primary DNS resolution and to the other DNS servers for secondary resolution.

Performance considerations

Take into account the additional overhead that is incurred by the domain controller services. In large networks running on Windows Server 2003 family operating systems, substantial resources can be required by domain controllers for performing directory replication and server authentication for clients. For this reason, many applications, such as Microsoft SQL Server and Message Queuing, recommend that, for best performance, you not install the application on domain controllers. However, if you have a very small network in which account information rarely changes and in which users do not log on and off frequently, you can use domain controllers as cluster nodes.


Capacity planning

After you assess your clustering needs, you are ready to determine how many servers you need and with what specifications, such as memory and hard disk storage.

This section covers:

  • Planning your groups
  • Determining server-capacity requirements


Planning your groups

You can take six steps to organize your applications and other resources into groups:

List all your server-based applications

Most groups contain one or more applications. Make a list of all applications in your environment, regardless of whether or not you plan to use them with the Cluster service. Your total capacity needs are determined by the sum of the total number of groups (virtual servers) that will run in your environment and the total amount of other software you will run independently of groups.

Sort the list of applications

Determine which of your applications can use failover. For more information, see Choosing applications to run on a server cluster.

Also list applications that will reside on cluster nodes but that will not use the failover feature because it is inconvenient, unnecessary, or impossible to configure the applications for failover. Although you do not set failover policies for these applications or arrange them in groups, they still use a portion of the server capacity.

Before clustering an application, review the application license, or check with the application vendor. Each application vendor sets its own licensing policies for applications running on clusters.

List all other resources

Determine which hardware, connections, and operating-system software a server cluster can protect in your network environment. For more information, see Addressing risks using server clusters.

For example, the Cluster service can fail over print spoolers, to protect client access to printing services. Another example is a file-server resource, which you can set to fail over, maintaining client access to files. In both cases, capacity is affected, such as the random access memory (RAM) required to service the clients.

List all dependencies for each resource

When you create this list, include all resources that support the core resources. For example, if a Web-server application fails over, the Web addresses and cluster storage devices containing the files for that application must also fail over if the Web server is to function. All these resources must be in the same group. This ensures that the Cluster service keeps interdependent resources together at all times.

Two guidelines for quantifying resources are:

  • A resource and its dependencies must be together in a single group.
  • A resource cannot span groups.

For example, if several applications depend on a particular resource, you must include all of those applications with that resource in a single group.

Make preliminary grouping decisions

Another factor in the way you assign groups is administrative convenience. For example, you might put several applications into one group because viewing those particular applications as a single entity makes it easier to administer the network.

A common use of this technique is to combine file-sharing resources and print-spooling resources in a single group. All dependencies for those applications must also be in the group. You can give this group a unique name for the part of your organization it serves, such as "Accounting File&Print." Whenever you need to intervene with the file- and print-sharing activities for that department, you would look for this group in Cluster Administrator.

Another common practice is to put applications that depend on a particular resource into a single group. For example, suppose a Web-server application provides access to Web pages, and that those Web pages provide result sets that clients access by querying a Microsoft SQL Server 2000 database application, through the use of Hypertext Markup Language (HTML) forms. By putting the Web server and the Microsoft SQL Server 2000 database in the same group, the data for both core applications can reside on a specific disk volume. Because both applications exist within the same group, you can also create an Internet protocol (IP) address and network name specifically for this resource group.

Make final grouping assignments

After you list the resources that you want to group together, assign a different name to each group, and create a dependency tree. A dependency tree is useful for visualizing the dependency relationships between resources.

To create a dependency tree, first write down all the resources in a particular group. Then draw arrows from each resource to each resource on which the resource directly depends.

A direct dependency between resource A and resource B means that there are no intermediary resources between the two resources. An indirect dependency occurs when a transitive relationship exists between resources. If resource A depends on resource B and resource B depends on resource C, there is an indirect dependency between resource A and resource C. However, resource A is not directly dependent on resource C.

The figure shows the resources in a final grouping assignment in a dependency tree.

Final grouping assignments, including dependencies

In the diagram, the File Share resource depends on the Network Name resource, which, in turn, depends on the IP Address resource. However, the File Share resource does not directly depend on the IP Address resource.

For information on using Cluster Administrator to set resource dependencies, see Setting resource properties.


Determining server-capacity requirements

After you choose a cluster model, determine how to group your resources, and determine the failover policies required by each resource, you are ready to determine the hardware capacity required for each server in the cluster. This topic explains the criteria for choosing computers for use as cluster nodes.

  • Cluster storage requirements

    • Each node in a cluster must have enough persistent storage capacity to store permanent copies of all applications and other resources required to run all groups. Calculate this for each node as if all of these resources in the cluster were running on that node, even if some or all of those groups run on other nodes most of the time. Plan these disk space allowances so that either node can efficiently run all resources during failover.

  • CPU requirements

    • Failover can strain the CPU processing capacity of a node when it takes control of the resources from a failed node. Without proper planning, the CPU of a surviving node can be pushed beyond its practical capacity during failover, slowing response time for users. Plan your CPU capacity on each node so that it can accommodate new resources without unreasonably affecting responsiveness.

  • Random access memory (RAM) requirements

    • When planning your capacity, make sure that each node in your cluster has enough RAM to run all applications that might run on either node. Also, make sure your paging files are set appropriately for each node's RAM.

    For more information about paging files, see Optimizing the paging file size and location and To change the size of the virtual memory paging file.

Notes

  • You can use the Windows DNA Performance Kit to test and tune the performance of your applications in your server cluster. For more information about the Windows DNA Performance Kit or about how to download the kit, see the Windows DNA Performance Kit link in Web Resources at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)


Planning for fault-tolerant disks

Many groups include disk resources for disks on shared buses. In some cases, these are simple physical disks, but in other cases they are complex disk subsystems containing multiple disks. Resources depend on the physical disk resource that represents the storage device. An unrecoverable failure of a disk resource results in certain failure of all resources that depend on that disk.

For these reasons, you might decide to use special methods to protect your disks and disk subsystems from failure. One common solution is the use of a hardware-based redundant array of independent disks (RAID). RAID support ensures the high availability of data contained on disk sets in your clusters. Some of these hardware-based solutions are considered fault tolerant, which means that data will not be lost if a member of the disk set fails.

Important

  • You cannot use software fault-tolerant disk sets for cluster storage.

This section covers:

  • Hardware redundant array of independent disks (RAID)
  • Error recovery


Hardware redundant array of independent disks (RAID)

The Windows Catalog contains many different hardware RAID configurations for clusters. Because many hardware RAID solutions provide power, bus, and cable redundancy within a single cabinet, and track the state of each component in the hardware RAID firmware, they provide data availability with multiple redundancy, protecting against multiple points of failure. Hardware RAID solutions can also use an on-board processor and cache.

XOX and XOX can use these disks as standard disk resources.

For more information on the different hardware RAID configurations, see the Microsoft Windows Catalog at Support resources.

Important

  • You cannot use software fault-tolerant disk sets for cluster storage.


Error recovery

With transaction logging and recovery, the NTFS file system ensures that the volume structure will not be corrupted, so all files remain accessible after a system failure. The NTFS file system also uses the recovery technique called cluster remapping. When the operating system returns a bad-sector error to the NTFS file system, NTFS dynamically replaces the disk cluster containing the bad sector and allocates a new disk cluster for the data. If the error occurs during a read, NTFS returns a read error to the calling program, and the data is lost (unless protected by RAID fault tolerance). When the error occurs during a write, NTFS writes the data to the new disk cluster, and no data is lost. NTFS puts the address of the disk cluster containing the bad sector in its Bad Sector file so that the bad sector is not reused.

Even with transaction logging and recovery and disk cluster remapping, user data can be lost due to hardware failure if you do not use a fault-tolerant-disk solution. For more information, see Planning for fault-tolerant disks.


Optimizing your clusters

Because Cluster service uses an adaptable architecture, it is able to allocate resources as needed to meet changing usage requirements. However, there are some hardware and configuration choices you can make to improve cluster performance. These choices are explained in the following sections:

  • Focusing on the right hardware resources
  • Optimizing the paging file size and location
  • Using additional TCP/IP services


Focusing on the right hardware resources

The goal in tuning the Cluster service and hosted applications is to determine which hardware resource will experience the greatest demand, and then to adjust the configuration to relieve that demand and maximize total throughput. Structure a system so that its resources are used efficiently.

For example, if the primary role of the cluster is to provide high availability of file and print services, high disk I/O usage will be incurred due to the large number of files being opened and closed. File and print services also cause a heavy load on network adapters because of the large amount of data that is being transferred. It is important to make sure that your network adapter can handle the load. In this scenario, memory typically does not carry a heavy load (although memory usage can be heavy if a large amount of system memory is allocated to file-system cache). Processor utilization is also typically low in this environment. In such cases, memory and processor utilization usually do not need the optimizing that other components need.

In contrast, a server-application environment (such as one running Microsoft SQL Server, Microsoft Exchange Server, Microsoft Systems Management Server, and Microsoft Systems Network Architecture (SNA) Server) is much more processor- and memory-bound than a typical file and print server environment because much more processing is taking place at the server. In these cases, it is best to use high-end multiprocessor computers. The disk and network loads tend to be less used because the amount of data being sent over the wire and to the disk is smaller. The Cluster service itself uses few of the system resources either for intracluster communication or for the operation of the cluster itself.


Optimizing the paging file size and location

The location and size of the paging files can greatly affect performance. Paging files cannot be located on the shared bus, but if multiple unshared drives are available on the individual servers, placing the paging file on a separate, fast, low-use drive can boost performance. The size setting of the paging file is also critical to performance. A paging file that must constantly expand and shrink requires additional processor and I/O overhead.


Using additional TCP/IP services

WINS, DHCP, and DNS Services use additional system resources, which you must consider before implementing any of these services on a cluster. In particular, WINS can require substantial overhead during peak logging on times in large networks. In such cases, make sure that your system has the necessary capacity to perform adequately.

Important

  • DNS is not clustered, but the node acts as the server of the service. If you run DNS on a node of a cluster, make sure to implement backup servers to provide redundancy, just as you would normally do on your network.


Using server clusters

This section provides information on how to use a server cluster to provide high availability application support.

  • Server cluster rules
  • Applying administrative procedures to server clusters
  • Cluster automation interface
  • General storage configuration tips for server clusters
  • Backing up and restoring server clusters
  • Uninstalling a server cluster
  • Cluster hardware configuration
  • Standard resource types
  • Managing security in a cluster
  • Using Cluster Administrator
  • Using a server cluster with large numbers of file shares
  • Using Shadow Copies of Shared Folders in a server cluster
  • Setting properties
  • Network management


Server cluster rules

Following these rules will help you solve the most common problems associated with clusters.

  • XOX or XOX must be installed on each node.
  • All nodes of the cluster must belong to the same Windows Server 2003 family operating systems domain; see Choosing a domain model.
  • When you first create the cluster or add nodes to the cluster, you must be logged on to the domain that has administrative user rights and permissions on all nodes.
  • Each cluster node can belong to only one cluster.
  • The shared drive must be formatted using the NTFS file system.
  • For 64-bit editions of XOX or XOX, cluster disks on a shared bus must be partitioned as MBR and not as GUID partition table (GPT) disks.
  • Do not change the computer name of a cluster node after configuring the first node of your cluster.
  • Do not repartition disks on the shared bus without first deleting the corresponding disk resources.
  • If you start the node using an operating system other than XOX or XOX, do not run any diagnostic tools that make low-level writes to a physical disk.
  • Do not reassign the drive letters of the system disks on the nodes.
  • Verify that either the WINS or DNS service is accessible from all nodes.
  • Verify that TCP/IP is installed on all nodes and clients.
  • Verify that all cluster nodes can detect one another over the network. Use the TCP/IP ping utility or the Windows Server 2003 family operating system net view command.
  • Check all event logs on all affected computers for error messages.

For information about how to obtain product support, see Technical support options.


Applying administrative procedures to server clusters

Typically, an administrator follows a set of server operating procedures when performing administrative tasks on a server, such as restarting a server, backing up applications and data, and installing new hardware or software. For a server cluster, reexamine these operating procedures; some will have to be modified in a server cluster environment.

Reexamining procedures that take a server cluster offline

Because you install Cluster Administrator on more than one computer, the tasks of administering servers and performing common server operating procedures are less disruptive to users. There are some administrative tasks that make a server unavailable to users. A server cluster, however, has another node that can continue to make the server resources available to users while you are performing administrative tasks. Therefore, you might not have to wait for nonpeak hours, when:

  • A server must be restarted.
  • New hardware must be installed.
  • New software must be installed.

Reexamining backups on a server cluster

Make sure that your backup procedures account for clustering issues. In a server cluster, the following procedure is recommended:

  1. Perform an Automated System Recovery (ASR) backup on each node in the cluster.

    Note

    • By default, Backup Operators do not have the user rights necessary to create an Automated System Recovery (ASR) backup on a cluster node. However, Backup Operators can perform this procedure if that group is added to the security descriptor for the Cluster service. You can do that using Cluster Administrator or cluster.exe. For more information, see To give a user permissions to administer a cluster and Cluster.
  2. Back up the cluster disks from each node.
  3. Back up each individual application (for example, Microsoft Exchange or Microsoft SQL Server) running on the nodes.

For more information, see Backing up and restoring server clusters.


Cluster automation interface

The cluster automation interface is a Component Object Model (COM) interface to the Cluster API. You can use the Cluster Automation Interface with the Windows Script Host (WSH) to automate many administrative tasks.

For more information on the Cluster API, see the Microsoft Platform Software Development Kit (SDK).


General drive configuration tips for server clusters

Microsoft Windows graphic

General storage configuration tips for server clusters

Before adding or removing hardware from a server cluster, make sure the drive letter assigned to the system partition (typically C or D) is fixed. The drive-letter assignment must remain constant because references to this drive letter are recorded in the system registry, and your server cluster is affected by these references.

It is also necessary for drive letters on the cluster storage device to remain constant and for the drive-letter assignments to be the same on each cluster node. In addition, drive letters for the cluster storage device must not conflict with any local drive letters.

If you assign drive letters to the shared cluster storage devices, the Windows Server 2003 family operating system limits the total number of such devices to 23. Mounted drives are not subject to this limit, so you can use mounted drives to access more than 23 shared cluster storage devices in your server cluster.

For more information on using mounted drives, see Using NTFS mounted drives.

For information about how to obtain product support, see Technical support options.


Backing up and restoring server clusters

Performing regular backups of your server cluster is imperative for high availability. This topic explains how you can use the Backup or Recovery Wizard to back up cluster nodes, describes ten cluster failure scenarios, and offers data restore solutions for each scenario using the Backup or Restore Wizard and recovery utilities from the Microsoft Windows Server 2003 Resource Kit.

For more information on backup and restore procedures, see Backing up and restoring data.

Backing up cluster data

In a server cluster, there are four groups of data critical to the proper operation of the cluster; the disk signatures and partitions of the cluster disks, the cluster quorum data, the data on the cluster disks, and the data on the individual cluster nodes.

Cluster disk signatures and partitions

Before you begin to back up any data on the server cluster nodes, make sure you backup the cluster disk signatures and partitions using Automated System Recovery in the Backup Wizard. This step is necessary if you later need to restore the signature of the quorum disk, for example, if you experience a complete system failure, and the signature of the quorum disk has changed since you last backed up.

Note

  • By default, Backup Operators do not have the user rights necessary to create an Automated System Recovery (ASR) backup on a cluster node. However, Backup Operators can perform this procedure if that group is added to the security descriptor for the Cluster service. You can do that using Cluster Administrator or cluster.exe. For more information, see To give a user permissions to administer a cluster and Cluster.

For information, see To back up cluster disk signatures and partition layouts.

Cluster quorum data

When you back up data on a server cluster node, make sure you also back up the cluster quorum. The cluster quorum is important because it contains the current cluster configuration, application registry checkpoints, and the cluster recovery log.

You can use the Backup Wizard to back up the cluster quorum data if you perform a System State backup from any node provided the Cluster service is running on that node.

For information, see To back up the cluster quorum.

Data on the cluster disks

To back up all cluster disks owned by a node, perform a full backup from that node.

You can also back up this data through a network connection to a hidden administrative file share. For example, you might use the New Resource Wizard to create FBackup$, GBackup$, and HBackup$ file shares for the root of drives F, G, and H, respectively. These shares would not appear in the browse list and could be configured to allow access only to members of the Backup Operators group.

For information on backing up data on the cluster disks, see To back up data on cluster nodes.

Important

  • If a cluster disk owned by the node being backed up fails over to another node during the backup process, the backup set will not contain a full backup of that disk.
  • You can only backup a cluster disk on a local node. You cannot backup a cluster disk on a remote computer.

Data on the individual cluster nodes

After you back up the cluster quorum disk on one node, it is not necessary to back up the quorum on the remaining cluster nodes. However, you may want to back up the clustering software, cluster administrative software, system state, and application data on the remaining nodes.

Important

  • If you back up the system state for a node, you will also automatically back up the quorum data as long as the Cluster service is running on that node.

For information on backing up data on individual cluster nodes, see To back up data on cluster nodes.

Cluster failure and restore scenarios

This section describes ten failure scenarios that will require restoring your cluster. The type of failure you experience determines the steps you must follow.

Scenario 1—Cluster Disk Data Loss

If you have lost files and folders on one of your cluster disks, but not on the disk containing the cluster quorum, you can use the Backup or Restore Wizard to restore that data.

Important

  • You must restore the cluster disk data from the node that owns the cluster disk.

For information, see To restore files from a file or a tape.

Scenario 2—Cluster Quorum Corruption

Symptom: The cluster nodes can boot up, but the Cluster service fails to start because the quorum resource cannot come online.

If this problem results from corrupted files on the quorum disk, follow the steps outlined in To recover from a corrupted quorum log or quorum disk. If the cluster quorum disk needs to be replaced, see Scenario 5, below. For a majority node set cluster, see Scenario 9, below.

Scenario 3—Cluster Quorum Loses Checkpoints

Symptom: Some resources fail to come online and the configuration data is out of date.

If you have recovered from quorum corruption by creating a new quorum log as described in Scenario 2 above, you may need to restore the matching checkpoints before the quorum resource can come back online.

Using the Microsoft Windows Server 2003 Resource Kit tools

  • Use the ClusterRecovery utility. For more information, see the Microsoft Windows Server 2003 Resource Kit.

Using Windows Server 2003 family tools

  • Locate backup sets of the cluster quorum disk and system disk. The cluster quorum disk backup will contain other system state data. These backups need to be a matched set, that is make sure they were taken at the same time.
  • Restore data on the system disk. For information, see To restore files from a file or a tape.
  • Restore the cluster quorum. For information, see Restore the contents of a cluster quorum disk for all nodes in a cluster.

Scenario 4—Cluster Disk Corruption or Failure

Symptom: The cluster disk cannot come online. Resources that depend on that cluster disk may also not be able to come online.

First, run the chkntfs command to determine if the disk is merely corrupted. For information, see Chkntfs command.

If the cluster disk is corrupted or the disk hardware fails, you can restore the disk while still keeping your cluster up and running by using utilities in the Microsoft Windows Server 2003 Resource Kit. If you do not have access to these tools, you can still restore your cluster disk using the Backup and Recovery utilities included with Windows Server 2003 family operating systems, but your cluster will not be in operation during the recovery process.

Using the Microsoft Windows Server 2003 Resource Kit tools

  • Locate the data backup set for the node that owns the cluster disk. Also, locate the Automated System Recovery backup set for that node, if it is available.
  • If necessary, replace the cluster disk. For information, see To install local storage buses and devices.
  • If you do have an Automated System Recovery backup set for the node, use the Confdisk utility from the Windows Resource Kit, along with NTBackup to restore the data on the cluster disk. For more information, see the Microsoft Windows Server 2003 Resource Kit.

    Notes

    • If you do not have the Automated System Recovery backup set, you can still restore the cluster disk by using the ClusterRecovery utility from the Microsoft Windows Server 2003 Resource Kit and the /fixquorum Cluster service start up parameter. For more information, see the Microsoft Windows Server 2003 Resource Kit.
    • If you use the Confdisk utility to restore your cluster disks, the checkpoints might not match.

Using the Microsoft Windows Server 2003 Resource Kit tools

  • If necessary, replace the cluster disk. For information, see To install local storage buses and devices.
  • Stop the Cluster service on all nodes of the cluster.
  • Perform an Automated System Recovery restore on the node that owns the failed cluster disk. For more information, see To restore a damaged cluster node using Automated System Recovery.
  • After the restored node comes back online, restart the Cluster service on the remaining nodes.

Scenario 5—Cluster Quorum Disk Failure

Symptom: The cluster nodes can boot up, but the Cluster service fails to start because the quorum resource cannot come online. Entries in the Event Log indicate hardware failures.

If the cluster quorum disk (the disk containing the quorum resource) fails, you can replace it while still keeping your cluster up and running by using utilities in the Microsoft Windows Server 2003 Resource Kit. If you do not have access to these tools, you can still replace your cluster quorum disk using the backup and restore utilities shipped with Windows Server 2003 family operating systems, but you must first bring down your cluster.

Using the Microsoft Windows Server 2003 Resource Kit tools

  • Locate the data backup set for the cluster quorum. Also, locate the Automated System Recovery backup set for the node you used to create the cluster quorum backup set, if it is available.
  • If necessary, replace the cluster quorum disk. For information, see To install local storage buses and devices.
  • If you do have an Automated System Recovery backup set for the node, use the Confdisk utility from the Microsoft Windows Server 2003 Resource Kit, along with NTBackup, to restore the data on the cluster disk. For more information, see the Microsoft Windows Server 2003 Resource Kit.

    Notes

    • If you do not have the Automated System Recovery backup set, you can still restore the cluster quorum disk by using the ClusterRecovery utility from the Microsoft Windows Server 2003 Resource Kit. For more information, see the Microsoft Windows Server 2003 Resource Kit.
    • If you use the Confdisk utility to restore your cluster quorum disk, the checkpoints might not match.

Using Windows Server 2003 family tools

  • Perform an Automated System Recovery restore on any node in the cluster. For more information, see To restore a damaged cluster node using Automated System Recovery.
  • Restore data on the node. For information, see To restore files from a file or a tape.

Note

  • Alternatively, you can also create a new quorum on another node, restart the cluster using the /fixquorum Cluster service start up parameter, and switch to the new quorum resource. For more information, see Fixquorum command.

Scenario 6—Single Cluster Node Corruption or Failure

Symptom: The node cannot join the cluster.

If the Event Log indicates that the cluster database on the local node is merely corrupted, you can perform a System State restore on that node to replace the local cluster database. For information, see To restore the cluster database on a local node. Alternatively, you can copy the latest checkpoint file (CHKxxx.TMP) from the quorum disk to the %systemroot%\Cluster\ directory, rename it as file CLUSDB, and restart the Cluster service on that node.

If a single node fails in the cluster due to system disk or other hardware failure, follow these steps to rebuild the node and rejoin the cluster:

  • After verifying that all cluster resource groups have been successfully moved to other nodes, repair or replace the failed hardware. For information, see To move a group to another node and To manage cluster hardware.
  • Perform an Automated System Recovery restore on the failed node to rebuild the node. For information, see To restore a damaged cluster node using Automated System Recovery.
  • If you have other files or application data for that node backed up on on tape or other backup medium, you can restore that now. For information, see To restore files from a file or a tape and Scenario 8 below.
  • For each cluster group and resource, verify that the newly recovered node appears as a possible owner in Cluster Administrator, then move a resource group to the newly recovered node and verify that the move is successful. For information, see To test whether group resources can fail over.

    • Note

    • If you do not have an Automated System Recovery backup of the node, you can evict that node and add a new node to the cluster. For more information, see To evict a node from the cluster and To add additional nodes to the cluster.

Scenario 7—Cluster Quorum Rollback

If your cluster is not functioning as expected, you can use the Backup or Restore Wizard to rollback your cluster to a previous configuration.

For information, see Restore the contents of a cluster quorum disk for all nodes in a cluster.

Scenario 8—Complete Cluster Failure

Symptom: None of the nodes can boot up.

If all nodes fail in a cluster and the quorum disk cannot be repaired, follow these steps:

  • Use Automated System Recovery on each node in the original cluster to restore the disk signatures and the partition layout of the cluster disks (quorum and nonquorum). For more information, see To restore a damaged cluster node using Automated System Recovery.
  • Recreate the original cluster, join all nodes to the cluster, and recreate the original Cluster group. For information, see Checklist: Planning and creating a server cluster.
  • Using the Backup or Restore Wizard, restore the cluster quorum on all nodes. For information, see Restore the contents of a cluster quorum disk for all nodes in a cluster.
  • Install cluster applications on each cluster node and recreate the cluster resources using the same names as before.
  • Restore your application data from backup data sets.

    • Important

    • If you do not have an Automated System Recovery backup of each node, you cannot restore the cluster. Instead, you must recreate your cluster from scratch. For more information, see Checklist: Planning and creating a server cluster.

Scenario 9—Majority Node Set Cluster Failure

On a majority node set cluster, the cluster database is not stored on a cluster disk central to all nodes, but is instead stored locally on each node at %systemroot%\Cluster\MNS.%ResourceGUID%$\%ResourceGUID%$\MSCS\. Because the majority node set cluster model does not use cluster disks, you can simply use the Backup or Restore Wizard to restore the data on individual nodes.

Using the full backup set for each node, restore data to each node in the cluster. For information, see To restore files from a file or a tape. The Cluster service will replicate the latest version of the cluster database to all other nodes.

If you want to restore an older version of the cluster database, stop the Cluster service on all nodes of the cluster and delete the local copies of the database (all the files under the \MSCS\ folder) on those nodes. Then restore the cluster database to one node and restart the Cluster service on all nodes. The Cluster service will replicate the restored version of the cluster database to all other nodes.

Note

  • If you do not have a backup of the cluster database and/or the cluster database files are corrupted, use the /resetquorumlog Cluster service start up parameter on one node of the cluster to create new cluster database files on that node. Then restart the remaining nodes. For more information, see Resetquorumlog command.

In a majority node set cluster, if some of the nodes fail, and the cluster loses quorum, you can force the remaining nodes to form a quorum and restart the cluster. For more information, see To force quorum in a majority node set server cluster.

Scenario 10—Application Data Loss in a Server Cluster

When restoring application data in a server cluster, follow the instructions provided in the documentation that shipped with your application.

Important

  • If you are backing up Microsoft Exchange Server, a newer version of NTBackup.exe may be available from the Exchange Server section of the Microsoft Web site (http://www.microsoft.com/). Otherwise, you can use the version of NTBackup.exe that is included with Windows Server 2003 family operating systems.


Uninstalling a server cluster

You can uninstall or remove a node of a server cluster at any time. Before uninstalling a node, take all groups offline or move them to one or more other nodes. Also, close Cluster Administrator.

For instructions on how to remove a node from a server cluster, see To evict a node from the cluster.


Cluster hardware configuration

This section covers:

  • Fibre Channel hardware configuration
  • Network configuration in a server cluster


Fibre Channel hardware configuration

Fibre Channel systems are a requirement for all server clusters running 64-bit versions of XOX or XOX and are recommended for clusters of 3 or more nodes. Make sure you know the following information about them:

  • The Fibre Channel systems are listed in a separate section of the Windows Catalog at Support resources. To list all compatible Fibre Channel devices, select All in Device Type, then in Model search for Fibre Channel.
  • Your Fibre Channel disks are managed just like any other disk connected to a storage bus.
  • The Fibre Channel controller ID is preconfigured with a unique ID. This simplifies your hardware setup because you do not need to manually configure each cluster node with a separate ID.

The figure shows a Fibre Channel cluster with a fiber switch or hub. Fiber optic cable runs between a node's Fibre Channel controller and the fiber switch or hub. The device bus between the switch or hub is fiber.

Fibre Channel Cluster


Network configuration in a server cluster

This section covers:

  • Configuring cluster network hardware
  • Private network addressing options


Configuring cluster network hardware

Planning your cluster network hardware and network infrastructure

Before you configure your cluster network hardware, make sure that your networking hardware and domain infrastructure meets all the requirements for a server cluster. For more information, see Planning your networking hardware and Choosing a domain model.

Network Interface Controller (NIC) configuration

Follow the guidelines below to correctly configure your cluster networking hardware:

Requirements

  • Your network adapters must use the same configuration settings.
  • Each network is on a single subnet.
  • At least one of the cluster networks enabled for internal communication (for example, either a private or mixed network) must be configured using static addresses.

Recommendations

  • If an adapter is set to use Auto Select, it may drop packets while automatically negotiating the network settings. Manually set the speed and duplex mode for multiple speed adapters to the same values and settings (set these properties on the Advanced tab of the network adapter's Property Page). If the adapters are connected to a switch, ensure that the port settings of the switch match those of the adapters. For more information, see To change network adapter settings.
  • Use static IP addresses for all adapters. Choose private IP addresses following the guidelines at Private network addressing options (that is, specify a class A, B, or C private address for each). For public networks, also use static IP addresses. It is recommended that you do not use DHCP leases for public network addresses because cluster operations might be disrupted. For more information, see The Cluster service and TCP/IP.

    The use of Automatic Private IP Addressing (APIPA) to configure a cluster network is not supported. APIPA is not designed for use in computers that are attached to multiple networks. For more information, see TCP/IP Configuration Methods.

  • Do not configure a default gateway or DNS or WINS server on the private network adapters.
  • Configure WINs and/or DNS servers and a default gateway on the public network adapters. If Network Name resources are used on the public networks, set up the DNS server to support dynamic updates; otherwise the Network Name resources may not fail over correctly. For more information, see To configure TCP/IP settings.
  • Set the order of the network adapter binding as follows:
    1. External public network
    2. Internal private network (Heartbeat)
    3. [Remote Access Connections]

    For more information, see To modify the protocol bindings order.

  • Clearly identify each network by changing the default name. For example, you could change the name of the private network connection from the default Local Area Connection to Private Cluster Network.

    • For more information on networks and network roles, see Server cluster networks.

Configuring logically multihomed network adapters

A logically multihomed network adapter is one that has two IP addresses assigned to it. These adapters can be used only for node-to-node cluster communication if their primary addresses are on the same IP subnet. If the primary addresses on all nodes are not on the same IP subnet, reorder the IP addresses assigned to the adapter by using the Network Connections folder.


Private network addressing options

If an interconnect connects only the cluster nodes and does not support any other network clients, you can assign it a private Internet protocol (IP) network address instead of using one of your enterprise's official IP network addresses.

By agreement with the Internet Assigned Numbers Authority (IANA), several IP networks are always left available for private use within an enterprise. These reserved numbers are:

  • 10.0.0.0 through 10.255.255.255 (Class A)
  • 172.16.0.0 through 172.31.255.255 (Class B)
  • 192.168.0.0 through 192.168.255.255 (Class C)

You can use any of these networks or one of their subnets to configure a private interconnect for a cluster. For example, address 10.0.0.1 can be assigned to the first node with a subnet mask of 255.0.0.0. Address 10.0.0.2 can be assigned to a second node, and so on. Do not specify any default gateway, DNS or WINS servers for this network.

Ask your network administrator which of the private networks or subnets you can use within your enterprise before configuring your cluster.

Never route these private network addresses. For more information on private IP network addresses, see Resources.


Standard resource types

XOX and XOX come with numerous resource types that you can use to manage cluster resources.

Internet Information Services (IIS) can be installed on a server cluster. For more information on how IIS runs on a server cluster, view the IIS online documentation.

If you have IIS installed, you can view the online documentation by typing http://localhost/iisHelp/ in your browser address bar and pressing ENTER.

You can install Message Queuing on a server cluster. For more information on the Message Queuing and Message Queuing Triggers resource types and how they run on a server cluster, see Message Queuing.

You can install Distributed Transaction Coordinator (DTC) on a server cluster. For more information on the Distributed Transaction Coordinator resource type and how it runs on a server cluster, see Component Services Administrative Tasks Overview.

Note

  • IIS Server Instance, Simple Mail Transfer Protocol (SMTP) Server Instance, and Network News Transfer Protocol (NNTP) Server Instance resource types, previously available on Windows 2000 cluster nodes, are not supported on XOX or XOX cluster nodes.

This section also covers the following resource types and topics:

  • Physical Disk resource type
  • DHCP Service and WINS Service resource types
  • Print Spooler resource type
  • File Share resource type
  • Internet Protocol Address resource type
  • Local Quorum resource type
  • Majority Node Set resource type
  • Network Name resource type
  • Generic Application resource type
  • Generic Script resource type
  • Generic Service resource type
  • Volume Shadow Copy Service Task resource type


Physical Disk resource type

You use the Physical Disk resource type to manage disks that are on a cluster storage device.

You can assign drive letters to the disks that are on a cluster storage device or create mounted drives. If you assign drive letters, the disks must have the same drive letters on all cluster nodes.

To prevent data corruption, it is important that only one node at a time use a cluster disk. Normally, the Cluster service prevents more than one node from using a disk at the same time. However, there are two circumstances in which the ordinary cluster safeguards do not work: when you install a new disk, and when you remove a disk from control by the cluster.

For information on replacing disks in a server cluster, see Updated technical information and article Q305793, "How to Replace a Disk with Windows 2000 or Windows Server 2003 family Clusters" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)


DHCP Service and WINS Service resource types

Dynamic Host Configuration Protocol (DHCP) and Windows Internet Name Service (WINS) provide network services to clients. DHCP leases Internet protocol (IP) addresses to clients. This lets you centrally manage IP addresses and related configuration details. For more information on DHCP, see DHCP. WINS provides a dynamic database service that can register and resolve NetBIOS names to IP addresses used on your network. For more information on WINS, see WINS.

XOX and XOX provide resource types that allow you to manage DHCP and WINS services in a cluster. Each of these resources stores a database on disk. In order for these resources to fail over, the database must be kept on a disk that is on cluster storage.

You must configure a location for the DHCP and WINS database files and for the backup of these files.

The path to the DHCP or WINS database files and backup of these files must:

  • End with a backslash (\).
  • Use a drive letter of a disk resource on which the DHCP or WINS resource depends.
  • Cannot begin with systemroot, although you can use other environment variables.

The path for the DHCP or WINS database will be of the form f:\dhcp\ or f:\wins\.

The path to the backup of the DHCP database files will be of the form f:\dhcp\backup\.

For WINS, you provide a root path, and the backup of the WINS database files is created in a subdirectory of this path. The path will be of the form f:\wins\.


Print Spooler resource type

You use the Print Spooler resource to cluster your print services. You can only cluster a printer that is connected to your servers by way of a network. If the printer is connected by way of a local port, such as LPT1, there is no way to fail over control of that printer in the case of failure of the server to which it is connected.

You cluster print services using the Print Spooler resource. Multiple Print Spooler resources can exist in a cluster, but there can be no more than one Print Spooler resource per group. Clients access clustered printers in exactly the same way they access nonclustered printers. Clients can use either the network name or Internet protocol (IP) address as the server name.

When a group containing a Print Spooler resource fails over to another node, the document that is currently being spooled to the printer is restarted from one of the other nodes after failover. When you move a Print Spooler resource or take it offline, the Cluster service waits until all jobs that are spooling to the printers are finished (or until the configured wait time has elapsed). Documents that are spooling from an application to a Print Spooler resource are discarded and must be respooled (or reprinted) to the Print Spooler resource if the group containing the Print Spooler resource fails over before the application has finished spooling.

In addition to creating a Print Spooler resource, you must properly configure your printer ports and printer drivers to function on a cluster. To properly set up a printer on a cluster, you must install printer drivers and a printer port on the same virtual server as the Print Spooler resource. The Cluster service will replicate the printer drivers from the virtual server to all cluster nodes the first time the Print Spooler resource fails over to another node.

For more information on the entire printing process in Windows Server 2003 family operating systems, see Understanding printing. For detailed instructions on how to configure a printer to operate in a cluster, see To create a cluster-managed printer.


File Share resource type

If you want to use a server cluster to provide a high availability file server you need to use the File Share resource type. You can use this resource type in three major ways:

  • Normal file share

    • You can use the File Share resource type to provide a basic file share. Using this method, a single file folder is published to the network under a single name and functions much as an Server Message Block (SMB) share does.

  • Share or hide subdirectories

    • You can also use the File Share resource to publish several network names: one each for a file folder and all of its immediate subfolders. This is an efficient way to create large numbers of related file shares on a single file server. An example application for this is creating a file share for each user who has files on the server. For more information on why you would want to share subdirectories, see Using a server cluster with large numbers of file shares. You can also prevent users from seeing the subdirectory shares when they browse the network. For more information on sharing or hiding subdirectories, see To share the subfolders on a File Share resource.

    Important

    • When you share subdirectories, do not use the same name for subfolders under different folders (for example, \folder1\name1 and \folder2\name1). The first shared subdirectory to come online will remain online, but the second shared subdirectory will not be initialized and will not come online.
  • DFS root

    • You can use the File Share resource type to create a resource that manages a stand-alone DFS root. Fault-tolerant DFS roots cannot be managed by this resource. The DFS root File Share resource has required dependencies on a network name and an Internet Protocol (IP) address. The network name can be either the cluster name or any other network name for a virtual server.

    A cluster-managed DFS root is very different from an Active Directory (or domain-based) DFS root. If the data that needs to be replicated is not changed very often, using a domain-based DFS root with replicas can be a better choice than a cluster-managed DFS root for providing high availability. If the data set changes frequently, replication is usually undesirable, and a cluster-managed DFS root is recommended.

    In XOX and XOX, server clusters support multiple standalone DFS roots. These multiple DFS roots can exist in multiple resource groups and each group can be hosted on a different node.

    Important

    • Clusters running XOX or XOX on some nodes and Windows 2000 on others will only support one DFS root per cluster.
    • Do not make DFS configuration changes (for example, by adding new links) while operating a mixed-version cluster.
    If you create multiple DFS roots in a single cluster, be aware of the following restrictions:
    • The name you specify for one DFS root cannot overlap with the names for other DFS roots in the same cluster. For example, if you named one DFS file share c:\dfsroots\root1, you could not share out other roots using names derived from the first DFS root, for example, c:\dfsroots, c:\dfsroots\root1, or c:\dfsroots\root1\root2.
    • The DFS roots must be hosted on NTFS partitions.
    • The name you give a non-clustered DFS root on a node's local storage must be different from the name you give a clustered DFS root on the cluster storage.

    For more information on DFS in a server cluster, see article Q301588, "Using DFS on a Server Cluster to Maintain a Single Namespace" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

    For more information on DFS, see Distributed file system.

When you create a new File Share resource, permissions for the Everyone group for that file share are automatically set by default to Read only. You can use Cluster Administrator or cluster.exe to change the default permissions. For more information, see To view or set resource properties.

You can also cache files from a cluster file share onto client computers. Clients can then have access to these files even when the client computer is disconnected from the network. For more information, see To set client-side caching for a File Share resource.

For more information on creating a highly available file share, see To create a cluster-managed file share.

You can also encrypt the data on your clustered file shares using Encrypting File System (EFS). For more information, see To create a cluster-managed encrypted file share.


Internet Protocol Address resource type

You use the Internet Protocol (IP) Address resource type to manage IP network addresses as cluster resources. When an IP Address resource is included in a group with a Network Name resource, the group can be accessed by network clients as a virtual server.

For more information on virtual servers, see Virtual servers.


Local Quorum resource type

You use the Local Quorum resource type to manage the system disk on the local node as the quorum resource. The Local Quorum resource cannot fail over to another node. If you create a new cluster on a node that is not connected to a cluster disk , the New Server Cluster Wizard will, by default, create a single-node cluster using the Local Quorum resource .

One scenario where a single-node cluster can be useful is in the development and testing of cluster-aware applications or custom resource types. For more information on how to create a cluster-aware application or custom resource type, see the Microsoft Platform Software Development Kit (SDK).

You can migrate an existing multinode cluster to a single-node cluster by creating a Local Quorum resource on one node, evicting all other nodes, and using the Local Quorum resource as the quorum resource. This can be useful if you need to troubleshoot cluster problems, for example on the cluster disk.


Majority Node Set resource type

You use the Majority Node Set resource type to manage cluster configuration data that may or may not be on a cluster storage device. For example, the Majority Node Set resource type can manage cluster configuration data that is actually stored on multiple nodes in a cluster at the same physical location or in a geographically dispersed cluster. The Majority Node Set resource ensures that the cluster configuration data is kept consistent across the different nodes. In contrast, in a single quorum device server cluster, the quorum resource maintains the definitive copy of the cluster configuration data on the cluster storage device.

Important

  • Only one Majority Node Set resource can exist in a server cluster.
  • Do not use the net use command to connect to the share containing the cluster database files (%systemroot%\Cluster\MNS.%ResourceGUID%$\%ResourceGUID%$\MSCS) in a majority node set server cluster. Otherwise, the Majority Node Set resource (the quorum resource) may be unable to connect to the share and may fail to come online.

For detailed instructions on creating a majority node set cluster, see To create a cluster.

For information on differences between a single quorum device server cluster and a majority node set server cluster, see Choosing a cluster model.


Network Name resource type

You use the Network Name resource type to provide an alternate computer name for an entity that exists on a network. When included in a group with an Internet Protocol (IP) Address resource, a Network Name resource provides an identity to the group, allowing the group to be accessed by network clients as a virtual server.

For more information on virtual servers, see Virtual servers.


Generic Application resource type

You use the Generic Application resource type to manage cluster-unaware applications.

When to use the Generic Application resource type

Not all applications will function effectively in a cluster. The minimum requirements for an cluster-unaware application are:

  • The application must be able to store its data in a configurable location.
  • The application must use TCP/IP to connect with clients.
  • Clients must reconnect in the event of intermittent network failure.

Installing a generic application

If your cluster-unaware application is to work during failover, you must make sure the application can run from all cluster nodes. There are two strategies for accomplishing this:

  1. Install the application onto a cluster disk. Because all nodes use the same drive letters for cluster disks, this solution guarantees that the application can be started from all nodes using the same command line.
  2. Install separate copies of the application on all cluster nodes. Make sure that the application is installed in a folder on each node that has the same drive letter and path as all other nodes. Although this solution uses more disk space, it is the only way you can install an application that will allow you to perform a rolling upgrade of that application.


Generic Script resource type

You use the Generic Script resource type to manage Windows Server 2003 family operating system scripts as cluster resources. Similar to the Generic Application resource type, the Generic Script resource type provides only the most basic functionality. If the script is running, it is presumed to be online. For more information on creating a generic script using Windows Script Host, see the Microsoft Platform Software Development Kit (SDK). To provide greater functionality, you can define a custom resource type. For more information on how to create a custom resource type, see the Microsoft Platform Software Development Kit (SDK).


Generic Service resource type

You use the Generic Service resource type to manage Windows Server 2003 family operating system services as cluster resources. Similar to the Generic Application resource type, the Generic Service resource type provides only the most basic functionality. For example, the failure of a Generic Service resource is determined by a query of the Service Controller. If the service is running, it is presumed to be online. To provide greater functionality, you can define a custom resource type. For more information on how to create a custom resource type, see the Microsoft Platform Software Development Kit (SDK).


Volume Shadow Copy Service Task resource type

With the Volume Shadow Copy Service Task resource type, you can create jobs in the Scheduled Task folder that must be run on the node that is currently hosting a particular resource group. In this way, you can define a scheduled task that can failover from one cluster node to another. However, in the Microsoft® Windows® Server 2003 family of products, the Volume Shadow Copy Service Task resource type has limited capabilities for scheduling tasks and serves primarily to support Shadow Copies of Shared Folders in a server cluster. If you need to extend the capabilities of this resource type, consider using the Generic Script resource type. For more information on the Generic Script resource, see Checklist: Installing a Generic Script resource.

For more information on shadow copies, see Shadow Copies of Shared Folders.

For more information on using the Volume Shadow Copy Service Task resource to manage shadow copies, see Using Shadow Copies of Shared Folders in a server cluster.


Managing security in a cluster

The Cluster service relies on Windows Server 2003 family security at all levels for securing communication between nodes, and controlling authentication and access, including client access to the cluster and cluster resources. You can use Cluster Administrator to specify which users or groups can:

  • Administer the cluster.
  • Access files or folders on File Share resources.

For more information on setting server cluster administration permissions, see To give a user permissions to administer a cluster.

For information on how to change the account or the password for the Cluster service, see To change the account under which the Cluster service runs and To change the Cluster service account password.

This section covers common security tasks:

  • Limiting client access to cluster resources
  • Securing shared data in a cluster
  • Domain accounts and the Cluster service
  • Disk resource security


Limiting client access to cluster resources

The following table lists the Windows Server 2003 family security features you can use to control client access to cluster resources.

Important

  • In general, grant permissions to the individual applications and services as you would normally. However, always use Cluster Administrator to set File Share resource security policies. File Share security policies configured using Windows Explorer are lost when the File Share resource fails over.
Resource type | Windows Server 2003 family security
Dynamic Host Configuration Protocol (DHCP) Service | Windows Server 2003 family DHCP security.
File Share | NTFS or share-level security configured with a cluster management application. NTFS file permissions strongly preferred. Only NTFS file permissions for subfolder shares. For information on administering DFS shares, see the DFS documentation.
Generic Application | Windows Server 2003 family network authentication and NTFS security applied to the shared file system.
Generic Service | Determined by Windows Server 2003 family service configuration.
Generic Script | NTFS file-level security for execute permissions on files and permissions for APIs called in the script.
IP Address | N/A
Distributed Transaction Coordinator | Controlled by Microsoft Distributed Transaction Coordinator (MS DTC).
Message Queue Service | Controlled by Message Queue Service.
Network Name | N/A
Physical Disk/Local Quorum | NTFS file-level security.
Print Spooler | Windows Server 2003 family network and print-level permissions.
WINS Service | Windows Server 2003 family WINS security.


Securing shared data in a cluster

Securing data on cluster disks

You can control access to folders and files of File Share resources on a user or group basis. You must set access to File Share resources through Cluster Administrator. The account used to start the Cluster service must have appropriate access to the directories with File Share resources. At minimum, this account must have NTFS Read permissions.

By default, access to cluster file shares is disabled to anonymous users. To allow anonymous access to specific file shares you can either enable Kerberos authentication on the Network Name resource associated with the file share or change the local security policy setting. For more information on configuring these Kerberos properties, see To enable Kerberos authentication for virtual servers.

Important

  • If you change file share permissions using Windows Explorer or My Computer instead of using Permissions on the Parameters tab in Cluster Administrator, the permissions are lost when the resource is taken offline.

When setting access permission on File Share resources, specify permissions based on, at minimum, a local Administrator group account; do not specify permissions based on local user or local group accounts. On member servers, local users and local groups have security context only on the local computer. The security context of these accounts and groups is meaningless when failed from one node to another. For this reason, you cannot give local users or local groups permissions to administer the cluster. The single exception to this rule is the local Administrators group. This is not a problem on domain controllers because the local accounts and groups have security context on all member servers in the domain.

Important

  • The Cluster service must always have full access to the folder on the quorum disk containing the quorum log (the folder is named MSCS by default). (The quorum log file is used to write all cluster state and configuration changes that cannot be committed to the other nodes.)

Encrypting shared data

You can further secure the contents of the data on your cluster disks by using Encrypting File System (EFS). EFS prevents unauthorized users that may gain physical access to your cluster disks from reading the data on those disks. For more information, see To create a cluster-managed encrypted file share.

Auditing access to shared data

Use standard security features to audit access to files and folders that reside on drives on the cluster storage. Use either My Computer or Windows Explorer to set file or directory auditing. You cannot do this using Cluster Administrator. For more information on auditing, see Auditing security events.

Security events are written to the security log on the node that owns the File Share resource.

Audit settings are specific to a node. Therefore, if you enable auditing on one node but not on another, you only see security events when the node with auditing enabled owns the File Share resource. If you want to audit access to shared data, it is a best practice to enable auditing on all cluster nodes.

Taking ownership of files or folders

Use either My Computer or Windows Explorer to set file or directory ownership. You cannot do this using Cluster Administrator.


Domain accounts and the Cluster service

You must log on using an account that is a member of an Administrators group to create the first node in a cluster or add additional nodes. All nodes must have joined a domain (instead of a workgroup) and be members of the same domain. When you create a cluster or join nodes to a cluster, you specify the domain user account under which the Cluster service runs. It is best if the Cluster service user account is a new account. The account must have local administrative rights and permissions on the cluster nodes. In addition, make sure that applications (for example, Microsoft SQL Server 2000) do not use the same account as the Cluster service account. Be sure to keep the password from expiring on the account (follow your organization's policies for password renewal).

When you install the operating system on a member server, Setup adds the Cluster service account as a member of the local Administrators group. When you install the operating system on a domain controller, Setup gives cluster-administrative permissions to the Domain Administrators group.

When you use Cluster Administrator to administer a cluster from a remote location, such as from another server or a computer running XOX, or to administer a cluster locally from a node, you must use an account that is a member of the local Administrators group on all nodes. For more information, see To give a user permissions to administer a cluster.

Note

  • You can use an account that is a domain user account or a member of a global group to remotely or locally administer a cluster if you use cluster.exe or cluster scripting tools. For more information, see Cluster and the Microsoft Platform Software Development Kit (SDK).

If you have administrative permissions on all nodes of the cluster, you can fully administer the cluster. However, if you have only specific permissions to administer the cluster, you cannot change the cluster description, change cluster security, or register extensions to Cluster Administrator.

For information on changing the account used to run the Cluster service, see To change the account under which the Cluster service runs.

For information on changing the password for the Cluster service account, see To change the Cluster service account password.


Disk resource security

There are two disk subsystems in a cluster environment: The first is the shared bus or buses, including the cluster disks, and the second is theWindows Server 2003 family operating system files. Keep these two systems separate. Do not put Windows Server 2003 family system files on the cluster disks. In addition, you can locate Windows Server 2003 family system files on either file allocation table (FAT) or NTFS drives, but you must locate the cluster disks on the shared bus only on NTFS-formatted drives.

Securing access to the cluster disks

Restrict access to the cluster disks to applications that are managed as a cluster resource. If there are other applications on a cluster node that are not managed by the cluster, install those applications either on the system disk or on a local disk. To help reduce the risk of unauthorized reads and writes to the quorum disk, it is recommended that you give access to the quorum disk only to the Cluster service account and members of the local Administrators group.

Securing disk resources on cluster disks

All standard Windows Server 2003 family file security options apply to the disk resources on the cluster disk. You can use Windows Explorer to set permissions on disk resources.


Using Cluster Administrator

Cluster Administrator shows you information about the groups and resources on all of your clusters and specific information about the clusters themselves. A copy of Cluster Administrator is automatically installed on your computer when you install XOX; XOX; or XOX.

Important

  • Cluster nodes must be running XOX or XOX. You cannot create a cluster or add nodes to an existing cluster on computers running XOX.

For remote administration, you can install copies of Cluster Administrator on other computers on your network running Windows Server 2003 family operating systems. Cluster Administrator is available through Windows Server 2003 Administration Tools, included on the XOX; XOX; and XOX compact disc sets. The remote and local copies of Cluster Administrator will be identical. It is also possible to administer a XOX or XOX server cluster remotely from a computer running Windows NT 4.0 Service Pack 3 or later using the Windows NT Server, Enterprise Edition 4.0, Cluster Administrator tool or from a computer running Windows 2000.

This section describes the uses of Cluster Administrator, including the ways in which it changes procedures you might have been familiar with in a noncluster environment.

  • Identifying failovers
  • Installing Cluster Administrator on a remote computer


Identifying failovers

Failover can occur in one of two situations: An entire node fails, or a resource on a node fails (such as a network interface). Node failure is easily identifiable in Cluster Administrator. When you are connected to a cluster, Cluster Administrator displays a list of all nodes and their current status. Resource failure that does not bring down a node, but does result in group failover, can be harder to detect. Use Cluster Administrator or another cluster management application to periodically check the owner of all cluster groups to see if a group has failed over.

It is important to use Cluster Administrator to routinely monitor the status of all clusters and check for failover activities that diminish either the performance or the availability of resources. Failover is supposed to be easily tolerated. Your work flow will not suffer if all applications are working, failover policies have been correctly set, and you have provided sufficient capacity for all situations. If any of these three criteria are not met, you must take action to meet them. For information on how to plan your server cluster, failover policies, and capacity requirements, see Planning your server cluster.

Serious failover situations can affect performance and availability. If a node fails and its companion node is unable to serve clients efficiently, the situation must be resolved immediately. If groups persistently fail over and fail back without surviving on either node for very long, availability to clients is completely lost.

Responding to a failover

When investigating possible problems with failovers, answer the following questions:

  • How serious is the problem?

    For example, other resources could be suffering due to the increased load placed on the alternate node.

  • What caused the failover?

    Many types of failure can cause failovers. Usually, these occur at the operating system and hardware levels. For help with determining the exact type of a failure, see Troubleshooting.

    To review what happened prior to and during a group failure, run Event Viewer and look at the application log, system log, and the security log (if applicable). This helps you determine what types of errors occurred.

  • Are any changes needed to prevent this kind of event in the future?

    If your performance has seriously suffered as a result of a failover, review the capacity planning issues presented in Capacity planning.

    If you determine that the nodes did not efficiently transfer control of various groups and resources during failover, review the failover policies you have set. For example, the Cluster service could be attempting to bring a File Share resource online before the corresponding Physical Disk resource was brought online. This type of error is easily fixed by configuring dependencies.

The Cluster service records error messages about resource failure in the system log. The system log is found in Event Viewer. The Event Properties dialog box contains error message information. Information about a resource failure might appear as follows:

Date: 9/8/2001
Time: 3:22:49 PM
Type: Error
Source: ClusSvc
Category: Failover Mgr
Event ID: 1069
User: N/A
Computer: DTCENTER3
Description: "Cluster resource 'Disk V:' in Resource Group 'SQL' failed.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp."

Other applications can keep track of such errors and notify appropriate parties as necessary.

For more information about diagnosing and resolving specific kinds of failures and errors, see Troubleshooting. For more information on resource dependencies, see Groups.

For information on how to solve failover problems, see Troubleshooting.


Installing Cluster Administrator on a remote computer

You can use Cluster Administrator to remotely administer a server cluster. Cluster Administrator runs on any computer that is running Windows NT 4.0 Service Pack 3 or later, Windows 2000, or a Windows Server 2003 family operating system. You can use Cluster Administrator on any computer running Windows 2000 or Windows Server 2003 family operating system to remotely create, join nodes, or manage a server cluster. On computers running Windows NT 4.0 Service Pack 3 or later, you can use Cluster Administrator just to remotely manage a server cluster.

Important

  • Computers used to remotely administer a server cluster must be secure and restricted to trusted personnel. For more information, see Best practices for securing server clusters.
  • When you remotely manage a cluster using Cluster Administrator or cluster.exe, you must verify that NetBIOS over TCP/IP (NetBT) is enabled on the client. For more information on enabling NetBIOS over TCP/IP, see To configure TCP/IP settings.

You use Windows Server 2003 Administration Tools to install Cluster Administrator on computers that are running Windows Server 2003 family operating systems that are not cluster nodes. On XOX; XOX; or XOX, Cluster Administrator is installed when you install the operating system. For more information on Windows Server 2003 Administration Tools, see Windows Server 2003 2003 Administration Tools Pack overview.

You cannot use Windows Server 2003 Administration Tools to install Cluster Administrator on a computer running Windows NT 4.0. However, if you have the version of Cluster Administrator that was provided with Windows NT Server, Enterprise Edition 4.0, you can use that version from any Windows NT 4.0, Service Pack 3 or later computer to administer a cluster running XOX or XOX. Because XOX and XOX provide resource types that were not supported in Windows NT 4.0, you might see error messages if you administer a cluster running XOX or XOX from a computer running Windows NT 4.0.

Caution

  • When remotely managing a server cluster from another computer, the system default locale on that remote computer can be different from the system default locale on all the nodes in the cluster only if the names of the cluster and all the cluster nodes use English language characters. For more information on changing the system default locale, see To change number, currency, time, and date settings.


Using a server cluster with large numbers of file shares

Every cluster resource you create has a performance impact; the Cluster service must periodically poll all resources to determine whether they have failed. Because of this, you may notice that your cluster's performance decreases as you increase the number of resources that it manages.

If you want to use a cluster to create a high availability file server that will have hundreds of file shares, consider managing those file shares using a single File Share resource. You can do this if the folders that you want to share on the network are all subfolders of a common folder. For example, if you use your file server to support hundreds of users, and each user has a private folder that is a subfolder of the Users folder, you can manage individual file shares for each user using a single File Share resource. You also have the option to hide the file shares that you create for each user so that they will not be visible when browsing. For information on sharing the subfolders of a folder and hiding the files shares you create, see To share subfolders on a File Share resource.

The maximum number of resources supported is 1674 (a maximum of 62 resource monitors each monitoring up to 27 resources).

For more information on how the Cluster service checks for failed resources, see Resource failure.


Using Shadow Copies of Shared Folders in a server cluster

Shadow Copies of Shared Folders provides point-in-time copies of files that are located on shared resources, such as a file server. You can use Shadow Copies of Shared Folders as part of your overall disaster recovery strategy to quickly recover files that were accidentally deleted or overwritten, as well as to compare different versions of files. However, there are several important considerations to keep in mind if you want to use Shadow Copies of Shared Folders on a cluster disk:

  • Cluster-managed shadow copies can only be created in a single quorum device cluster on a disk with a Physical Disk resource. In a single node cluster or majority node set cluster without a shared cluster disk, shadow copies can only be created and managed locally.
  • The recurring scheduled task that generates volume shadow copies must run on the same node that currently owns the storage volume.
  • The cluster resource that manages the scheduled task must be able to fail over with the Physical Disk resource that manages the storage volume.

The Volume Shadow Copy Service Task resource type can be used to manage shadow copies in a server cluster. The Volume Shadow Copy Service Task resource used in this way has a required dependency on the Physical Disk resource.

For more information on shadow copies, see Shadow Copies of Shared Folders.

For more information on the Volume Shadow Copy Service Task resource type, see Volume Shadow Copy Service Task resource type.

Best practices for using shadow copies in a cluster

  • To improve server performance, use different disks for the shadow copy volume and the storage volume.

    Note

    • You cannot create storage volume associations between distinct volumes on a disk managed by a single Physical Disk resource.
  • If you have multiple shadow copy volumes, use a single, separate disk for the storage volume.
  • Do not enable shadow copies in a deployed cluster. When you enable shadow copies, the shadow copy volumes (as well as all resources that directly or indirectly depend on the disk) go offline for a brief period while the resource dependencies are created. The shadow copy volumes are not accessible to applications and users while they are offline.
  • Enable shadow copies after you have created your cluster. If you enable shadow copies before clustering your servers, you must disable, then reenable, shadow copies.

    Note

    • If you cluster a disk containing a previously-created shadow copy, the shadow copy may stop functioning once that disk's Physical Disk resource fails over.

Using Cluster Administrator or cluster.exe to manage shadow copies

Important

  • Using Cluster Administrator or cluster.exe to completely configure and manage shadow copies in a cluster is not a supported scenario. The only supported scenario for configuring shadow copies in a cluster is described in To enable Shadow Copies of Shared Folders in a cluster.

For more information on using Cluster Administrator to create a Volume Shadow Copy Service Task resource, see Checklist: Installing a Volume Shadow Copy Service Task resource.

For more information on using cluster.exe to create a Volume Shadow Copy Service Task resource, see Cluster resource.

Enabling shadow copies on a cluster node

When you enable shadow copies on a cluster node (for example, by using the Configure Shadow Copy user interface through the Computer Management MMC ), a Volume Shadow Copy Service Task resource and a scheduled task for creating that shadow copy are automatically generated and configured. You do not need to explicity create the Volume Shadow Copy Service Task resource using Cluster Administrator or cluster.exe. In addition, the Configure Shadow Copy user interface automatically sets up the required resource dependencies. The default properties of the scheduled task and Volume Shadow Copy Service Task resource are described in the table below. For more information, see To enable Shadow Copies of Shared Folders in a cluster.

Scheduled task property | Volume Shadow Copy Service Task resource Cluster Administrator property (cluster.exe property) | Default setting
Name of task Name of resource (TaskName) ShadowCopyVolume{VolumeGUID}

Note

  • The name of the scheduled task is the same as the name of the Volume Shadow Copy Service Task resource associated with that task.
Run Command to run/Command parameters (ApplicationName/ApplicationParams) %systemroot%\system32\vssadmin.exe Create Shadow /AutoRetry=5 /For=\\?\Volume{VolumeGUID}\

For more information, see Vssadmin.
Creator | n/a | Cluster service
Start in | Start in | %systemroot%\system32\
Run as | n/a | Local System
Schedule Schedule (TriggerArray) The default settings used by Shadow Copies of Shared Folders.

For more information, see Defining a schedule for shadow copies.


Setting properties

After setting up your cluster, you might need to change the configuration of some resources and groups from time to time. To make changes to a selected group or resource, on the File menu, click Properties.

For detailed procedures on setting properties for groups, resources, networks, and network interfaces, see How to.

This section covers:

  • Setting group properties
  • Setting resource properties
  • Setting network properties
  • Setting network interface properties
  • Setting node properties
  • Setting resource type properties


Setting group properties

Using the group Properties dialog box, you can:

  • View the state of the group (whether it is online or offline) and view which node currently owns the group.
  • Change the group name, description, and preferred owner.
  • Set the failover policy (using the Failover tab).
  • Set the failback policy (using the Failback tab).

Do not update the properties of a cluster object on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).

Setting failover policy

Use the Failover tab to set failover policy for the group. You can set the following:

  • The failover threshold
  • The failover period
  • Whether or not a failure of one resource affects other resources in the group.

    By default, if one or more resources fail in a group, the Cluster service fails all other resources in the group.

The failover threshold is the number of times the group can fail over within the number of hours specified by the failover period. For example, if a group failover threshold is set to 5 and its failover period to 3, the Cluster service will fail over the group at most five times within a three-hour period. The sixth time a resource in the group fails, the Cluster service fails all other resources in the group and leaves the entire group offline instead of failing over the group. If the Effect the Group failover option is disabled, and a resource in the group fails for a sixth time, the Cluster service leaves the resource in the offline state instead of failing all other resources in the group. For example, if the Effect the Group option was disabled and a Network Name resource failed six times in three hours, on the sixth failure the Network Name would be left offline. An IP Address resource, however, would be left online.

Setting failback policy

By default, groups are set not to fail back. Unless you manually configure your group to fail back after failing over, it continues to run on the alternate node after the failed node comes back online.

When you configure a group to automatically fail back to the preferred node, you specify whether you want the group to fail back as soon as the preferred node is available or to fail back only during specific hours that you define. This option is useful if you want the failback to occur after peak business hours or if you want to make sure the preferred node is able to support the group when it does come back online.

The group must be configured to have a preferred owner to fail back. You can specify a preferred owner on the General tab of the group Properties dialog box.

For instructions on how to open the Properties dialog box, see To change the properties of a group.


Setting resource properties

Using the resource Properties dialog box, you can:

  • View or change the resource name.
  • View or change the resource description and possible owners.
  • Specify whether the resource runs in a separate memory space.
  • View the resource type, group ownership, resource state, and which node currently owns the resource.
  • View preexisting dependencies and modify resource dependencies.
  • Specify whether to restart a resource and, if so, what settings to use to restart.
  • Specify how often you want the Cluster service to check whether the resource is in the online state (by setting the Looks Alive and Is Alive polling intervals).
  • Specify the amount of time that a resource in a pending state (Online Pending or Offline Pending) has to resolve its status before the Cluster service puts the resource in Offline or Failed status.
  • Set specific resource parameters.

The General, Dependencies, and Advanced tabs are the same for every resource. Some resource types support additional tabs.

Do not update the properties of a cluster object on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).

Setting resource dependencies

The Cluster service uses the dependencies list when bringing resources online and offline. For example, if a group is brought online in which a physical disk and a file share are located, it is futile to try to bring the file share online before bringing the physical disk (on which the file share is located) online. It is important to remember this when you configure resources because the groups function properly only if these dependencies are correctly configured.

The following table shows resources and their dependencies. The resources in the right column must be configured before you create the resource.

Resource | Dependencies (required or recommended)
DHCP Service Physical Disk or other storage class device (on which the files are located)

Internet Protocol (IP) Address (for client access to the DHCP server)

Network Name (for client access to the DHCP server)
Distributed Transaction Coordinator | Physical Disk or other storage class device
File Share

A file share that is configured as a DFS root has the following required dependency:

  • Network Name

A file share that is not DFS has no required dependencies. It is recommended that file share resources have the following dependencies:

  • Physical Disk
  • Network Name
Generic Application | Network Name
Generic Script | None
Generic Service | Network Name
IP Address | None
Local Quorum | None
Majority Node Set | None
Message Queuing Physical Disk or other storage class device

Network Name (so that remote clients can access it)
Network Name | IP Address (that you want to correspond to the name)
Physical Disk | None
Print Spooler Physical Disk or other storage class device (on which the spool is located)

Network Name (so that remote clients can access it)
Volume Shadow Copy Service Task | A Volume Shadow Copy Service Task resource has no required dependencies. However, Volume Shadow Copy Service Task resources that manage scheduled tasks for shadow copies have a required dependency on the Physical Disk resources for the volumes on which the volume shadow copies are located.
WINS Service Physical Disk or other storage class device (on which the files are located)

Network Name (for client access to the WINS server)

Note

  • The Network Name will, in turn, be dependent on the IP Address which is necessary for client access to the WINS server.

The New Resource Wizard enforces the use of resource dependencies.

Setting advanced resource properties

Use the Advanced tab of the resource Properties dialog box to:

  • Specify whether the Cluster service attempts to restart a resource or allows the resource to fail.
  • If you want the Cluster service to restart the resource, you must specify whether to affect the group. If you want the group to be failed over when this resource fails, select the Affect the group check box, and then enter the values you want in Threshold and Period. These values determine how many times the Cluster service attempts to restart the resource before failover and the amount of time in which the threshold number of restart attempts takes place. If the Affect the group check box is not selected, a failure of this resource never causes the group to fail over.
  • Specify how often the Cluster service makes a cursory check (Looks Alive) or in-depth check (Is Alive) to determine if a resource is in the online state.
  • Click Use resource type value to use the default number for the resource type.
  • Specify the amount of time that a resource in a pending state (Online Pending or Offline Pending) has to resolve its status before the Cluster service puts the resource in Offline or Failed status.

Setting resource parameters

Most resources have a resource-specific Parameters tab in their Properties dialog box. The following table lists each resource and its configurable parameters.

Resource | Configurable parameters

DHCP Service

You can enter the path to the DHCP database files and to the backup of the DHCP database files.

You can enter the path to the audit log file stored by the DHCP service.
Distributed Transaction Coordinator | None.
File Share You can use the Parameters tab for the File Share Properties dialog box to set permissions on the file share and limit the number of simultaneous users.

Important

  • When you create a new File Share resource, permissions for the Everyone group for that file share are automatically set by default to Read only. You can use Cluster Administrator or cluster.exe to change the default permissions. For more information, see To view or set resource properties.

You can also use the Parameters tab to set the name of the file share (because clients will detect it in their browse or explore lists), set the file share comment, and set the path to the shared files.
Generic Application You can use the Parameters tab in the Generic Application Properties dialog box to specify the application command line, current directory, whether it uses the Network Name for the computer name, and whether or not it can interact with the desktop.

Important

  • It is recommended that you carefully consider the ways in which you interact with the server before you enable the Generic Application to interact with the desktop. This option is not valid in a number of scenarios, for example, administering a cluster either in a terminal server session or remotely using Emergency Management Services and an out-of-band connection.
Generic Script | You can use the Parameters tab for the Generic Script Properties dialog box to specify the path to the Visual Basic (VB) script file.
Generic Service | You can use the Parameters tab for the Generic Service Properties dialog box to specify the service name, startup parameters, and whether it uses the Network Name for the computer name.
IP Address | You can configure the IP address and subnet mask. You must also specify which cluster network to use and enable NetBIOS for the IP address.
Local Quorum | None.
Majority Node Set | None.
Message Queuing | None.
Network Name | You can configure the computer name parameter, enable Kerberos authentication, and indicate whether DNS registration failures are tolerated for the Network Name resource.
Physical Disk | You can specify only which drive to use for the Physical Disk resource. You cannot change this after the resource is created.
Print Spooler | You can configure the path to the Print Spooler folder and the job completion time-out for the Print Spooler resource.
Volume Shadow Copy Service Task You can use the Parameters tab for the Volume Shadow Copy Service Task Properties dialog box to specify the command to run for the task (a combination of the Command to run and Command parameters fields), the working directory, and the schedule for running that command.

Important

  • These parameters are automatically set when you enable shadow copies on cluster nodes. For more information, see To enable Shadow Copies of Shared Folders in a cluster.
WINS Service | You can enter the path to the WINS database files and to the backup of the WINS database files.


Setting network properties

After setting up your cluster, you might need to change the configuration of the networks that support client-to-cluster communication and node-to-node communication. For detailed procedures on setting network properties, see Manage networks.

Using the network Properties dialog box, you can:

  • View or change the network name.
  • View or change the network description.
  • Enable or disable the network for cluster use. If you enable the network for cluster use, you can specify whether to use the network for only client-to-cluster communication, only node-to-node communication, or both.
  • View the network's state.
  • View the network ID.
  • View the subnet mask.

Do not update the properties of a cluster object on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).

Setting network priorities

Cluster nodes can communicate over multiple networks. You can change the network's priority to specify the order in which the nodes will attempt to communicate over the networks. For detailed instructions on changing the network priority, see To change network priority for communication between nodes.

For server clusters with three or more nodes running XOX or XOX, the semantics behind heartbeat multicasting determine the priority of the networks used for intracluster multicast communication. For example, if an internal-use network with the highest priority has heartbeat multicasting disabled, then intracluster multicast traffic may be transmitted over a lower priority network even though the highest priority network is fully operational.

For more information on heartbeats, see Network communication between nodes.


Setting network interface properties

After setting up your cluster, you might need to change the configuration of the network interfaces. For detailed procedures on setting network interface properties, see Manage networks.

Using the network interface Properties dialog box, you can:

  • View the node and network object name.
  • View or change the network interface description.
  • View the network interface's state.
  • View the name of the network adapter for the network interface.
  • View the network interface's Internet Protocol (IP) address.

Do not update the properties of a cluster object on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).


Setting node properties

Using the node Properties dialog box, you can:

  • View the node object name.
  • View or change the node description.
  • View the node's state. A node's state can be:

      Down. The node is not actively participating in cluster operations.

      Joining. The node is in the process of becoming an active participant in the cluster operations.

      Paused. The node is actively participating in cluster operations but cannot take ownership of resource groups and cannot bring resources online.

      Unknown. The state could not be determined.

      Up. The node is actively participating in all cluster operations.

  • View the version and build number of the Cluster service.

Do not update the properties of a cluster object on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).


Setting resource type properties

Using the resource type Properties dialog box, you can:

  • View or change the resource type display name. The display name is used to manage the resource type in the cluster administration tools.
  • View or change the description of the resource type.
  • View the nodes on which the resource type can run.

  • View or change the default poll intervals (in milliseconds) for resources of this type. The poll intervals are Looks Alive and Is Alive.

    The Looks Alive poll interval specifies how often the Cluster service checks the state of the resource to determine whether or not the resource appears to be active. You can use the default value for the resource type or specify a number in milliseconds.

    The Is Alive poll interval specifies how often the Cluster service checks whether the resource is active. You can use the default value for the resource type or specify a number in milliseconds.

  • View the type name of the resource type. The type name is used internally by APIs and resource dynamic-link libraries (DLLs).
  • View the DLL file that implements the behavior of this resource type.
  • View whether resources of this type can be used as a quorum resource. The only quorum-capable resource types currently provided by Microsoft are the Physical Disk, Majority Node Set, and Local Quorum resource types. For more information on quorum resources, see Quorum resource. For more information on the Physical Disk, Majority Node Set, and Local Quorum resource types, see Physical Disk resource type, Majority Node Set resource type, and Local Quorum resource type.

Do not update the properties of a cluster object on multiple nodes simultaneously. For more information on multiple and simultaneous property updates, see the Microsoft Platform Software Development Kit (SDK).


Network management

This topic describes features of server clusters that affect network management:

  • Plug and Play network support
  • Name coordination between Cluster service and Network Connections
  • Network failure detection and recovery


Plug and Play network support

Using the Plug and Play technology built into Windows Server 2003 family operating systems, the Cluster service detects the addition and removal of TCP/IP networking components. For example, the Cluster service can detect the following events:

  • Addition or removal of network adapters
  • Binding or unbinding the TCP/IP protocol stack to a network adapter
  • Addition or release of a DHCP-assigned or static Internet protocol (IP) address

When a new network adapter is added to the computer and bound to TCP/IP using a subnet not already in use by the Cluster service, the Cluster service adds a network interface object to the cluster. If the network interface is connected to a new network, the Cluster service also adds a new network object to the cluster. You do not need to restart the Cluster service for these changes to take place. By default, the newly created interface and network objects are used for mixed communication, that is for both client and internal cluster communication.

Similarly, if a TCP/IP stack is removed, the Cluster service removes the corresponding network interface object from the cluster. If that network interface is the last interface connected to a network, the Cluster service removes the network object from the cluster.

If one network adapter is removed from a node, all IP Address resources dependent on that adapter will attempt to failover to another node. If all network adapters in the cluster are removed (that is, reconfigured or connected to a different physical network), all dependent IP Address resources go offline and are "orphaned," that is, their associated network is empty. If another network adapter is then added and assigned to the same subnet as the orphaned IP Address resource, the resource is reassociated with the "new" network; it is new in the sense that it has a different GUID and is a new instance of a network that has the same properties as the "old" network.

For more information on configuring network objects, see Setting network properties. For more information on configuring network interface objects, see Setting network interface properties.


Name coordination between Cluster service and Network Connections

In the Windows Server 2003 family, each physical network adapter in a computer is represented by a named icon in the Network Connections folder. The Cluster service coordinates the names of its network interface objects with the names of the icons in the Network Connections folder.

Automatic renaming of networks

Windows Server 2003 family operating systems automatically ensure that both a server cluster and the Network Connections folder use the same name to reference any individual network interface. For example, if you use any cluster administration tool to rename a cluster network object, the Windows Server 2003 family operating system automatically renames the corresponding icon in the Network Connections folder. Similarly, if you rename a network connection icon in the Network Connections folder, the Windows Server 2003 family operating system renames the matching cluster network object, if one exists.

The Windows Server 2003 family operating system ensures that cluster nodes also use the same name for the network object and corresponding icons in the Network Connections folder. Therefore, if you rename a cluster network object on one node of a cluster, the name of the network object on the other nodes and the icon name in the Network Connections folders on all nodes also change. The operating system does not notify you when it renames a related cluster network object or icon in a Network Connections folder.

The following table summarizes the actions the Windows Server 2003 family operating system takes in response to any renaming you perform.

Action | Result
Set up a new cluster. | The Windows Server 2003 family operating system uses the names of the icons in the Network Connections folder as the default names for cluster network objects. If you choose to rename any of the cluster network objects, the operating system renames the corresponding icon in the Network Connections folder.
Add a new node to an existing cluster. | The Windows Server 2003 family operating system renames icons in the Network Connections folder to match the names of the cluster network objects.
Rename a network object using a cluster administration tool. | The corresponding icon in the Network Connections folder is renamed on all cluster nodes.
Rename an icon in the Network Connections folder. | The Windows Server 2003 family operating system renames the corresponding cluster network object. It renames the corresponding icon in the Network Connections folder on the other node.

Network name conflicts

When you change the name of a network object or an icon in the Network Connections folder on one node of a cluster, you introduce the possibility of a naming conflict. For example, assume you have a cluster consisting of Node 1 and Node 2, and you change the name of a cluster network object on Node 1 from Public Network to Corporate Network. If an icon in the Network Connections folder on either Node 1 or Node 2 is already named Corporate Network, then the renaming attempt creates a name conflict.

Windows Server 2003 family operating systems prevent name conflicts by appending a number to any existing icon or network object names that would cause a name conflict with whatever new name you enter. In the previous example, the operating system renames the existing Corporate Network icon to Corporate Network (2). This feature ensures that whenever you attempt to rename a network object or an icon in the Network Connections folder, your renaming attempt succeeds without generating any name conflicts.


Network failure detection and recovery

The Cluster service is able to detect and isolate network failures. The Cluster service uses its improved network failure detection to improve failure recovery actions.

This section describes the Cluster service network state management and failure recovery process:

  • Network state management and failure detection
  • Network-failure recovery


Network state management and failure detection

XOX and XOX use sophisticated algorithms to monitor the health of network interfaces in a server cluster. The following tables summarize the states that a network interface and a network can be in.

Network interface states

State | Description
Failed

The node that owns the network interface is active; however, it cannot communicate through its network interface. The Cluster service has determined that the error is isolated to the network interface.

XOX and XOX use several methods to determine whether failures are isolated to network interfaces. First, the Cluster service uses a heartbeat to help detect network problems. Second, the operating system can receive hardware failure notifications from a network adapter that supports the Network Driver Interface Specification (NDIS). Using network adapters that support newer NDIS features, for example, media sense, improves cluster network state management. Finally, the Cluster service attempts to ping external hosts to estimate the scope of a network interface failure. This can cause a temporary increase in network traffic while the operating system investigates the extent of a network failure.

Note

  • When a failed network adapter is replaced, the Cluster service will determine that the new card is the interface for an existing network if the card is on the same subnet.
Unavailable | The network is disabled for cluster use, or the node associated with this network interface is down.
Unreachable | The node cannot communicate through this network interface. The reason for the failure is unknown.
Up | The network interface is active and can communicate with all other interfaces on the network (except those currently in Failed or Unavailable states). Up is the normal operational state.
Unknown | The state cannot be determined.

Network states

State | Description
Down | The network has failed. None of the active nodes in the cluster can communicate with one another using this network.
Unavailable | The network is disabled for cluster use, or all of the cluster nodes attached to this network are inactive.
Partitioned | The network has partially failed. Some active cluster nodes cannot communicate with one another over this network.
Up | The network is functioning normally. Up is the normal operational state.
Unknown | The state cannot be determined.


Network-failure recovery

When a network interface enters the Failed state, the Cluster service triggers the failure of all IP Address resources that use that network interface. When an IP Address resource fails, the Cluster service treats it like the failure of any other resource: All resources that depend on the IP Address resource fail, and the Cluster service uses the failover policy that you have set to determine whether or not to fail over the resource group.

The Cluster service does not trigger the failure of IP Address resources when a network interface enters the Unreachable state. If the network interface is in the Unreachable state, the Cluster service has not isolated the network problem enough to implement an appropriate recovery policy. When a network interface enters the Unreachable state, investigate the state of the network to determine whether or not to cause a manual failover of resource groups.


Administering server clusters

You can use cluster commands to administer a server cluster and the Cluster service from the command prompt.

  • Managing a server cluster from the command line
  • Managing the Cluster service from the command line


Managing a server cluster from the command line

You can use cluster commands to create, configure, and administer server clusters from the command prompt. You can also call the program Cluster.exe from command scripts to automate many cluster administration tasks. Cluster.exe is provided on all computers running Windows Server 2003 family operating systems.

You can use Cluster.exe to create, configure, and administer clusters from a node of the cluster, from nodes of other clusters, or from other computers running Windows NT 4.0 with Service Pack 3 or later.

Caution

  • When using cluster.exe to manage a server cluster, the locale settings for the user account must match the system default locale on the computer used to manage the cluster. If you remotely manage a server cluster from another computer, the system default locale on that remote computer can be different from the system default locale on all the nodes in the cluster only if the names of the cluster and all the cluster nodes use English language characters. For more information on changing the system default locale, see To change number, currency, time, and date settings.

Important

  • When you remotely manage a cluster using Cluster Administrator or cluster.exe, you must verify that NetBIOS over TCP/IP (NetBT) is enabled on the client. For more information on enabling NetBIOS over TCP/IP, see To configure TCP/IP settings.

You can also start the Cluster Administration tool at a command prompt using the Cluadmin.exe command.

For information about other command-line utilities, see Command-line reference. For more information about manageability, see Understanding Windows Management.

The following rules apply to cluster.exe and its subcommands when entering commands from the command prompt:

  • You must use quotation marks around all names that contain spaces and special characters. Examples of special characters are: the minus sign (-), the slash mark (/), quotation marks ("), the colon (:), the comma (,), and the equal sign (=). For other examples, see the cluster commands in Related Topics.
  • When setting properties to True or False, specify 1 (one) for True and 0 (zero) for False.
  • You specify the local cluster when you enter a PERIOD (.) in the command for cluster name.
  • You can specify multiple options for one command line. Cluster.exe processes options from left to right. If an option fails, the command will stop executing at the failed option.
  • Use double quotation marks (") in a string that has two consecutive double quotation marks (""). The following example shows double quotation marks in a string:

    cluster resource AResource /priv aProp="a """

This section describes cluadmin.exe as well as the cluster.exe commands, command abbreviations, and property lists:

  • Cluadmin
  • Cluster
  • Cluster node
  • Cluster group
  • Cluster network
  • Cluster netinterface
  • Cluster resource
  • Cluster resourcetype
  • Cluster command abbreviations
  • Property lists


Managing the Cluster service from the command line

You can use cluster service commands to troubleshoot or debug the Cluster service from the command prompt. The Cluster service command line can only be run locally from the cluster directory:

%systemroot%\cluster

Do not use the clussvc command under normal conditions, but only as a temporary diagnostic tool if the Cluster service fails to start (because of a system-related error, for example).

Important

  • If you use the clussvc command to start the Cluster service in a server cluster with 3 or more nodes, the Cluster service will be unable to authenticate any intracluster messages sent in multicast mode. The intracluster traffic in the server cluster will then revert to unicast mode. However, this will not affect the ability of any node to participate in the server cluster. For information, see Network communication between nodes.
  • Do not change the Cluster service account password while running the Cluster service from the command line. For information on changing the Cluster service account password, see To change the Cluster service account password

For information about other command-line utilities, see Command-line reference. For more information about manageability, see Understanding Windows Management.

The following rules apply when entering commands from the command prompt:

  • When entering commands from the command prompt, you can specify multiple options for one command line. Clussvc.exe processes options from left to right. If an option fails, the command stops running at the failed option.
  • To use the Cluster service commands, you must be logged on with administrative rights.
  • To stop the Cluster service, at the command prompt, press CTRL+C.

The command line for starting the Cluster service has the following syntax:

clussvc /debug [command]

The Cluster service runs in the command prompt window and displays all output recorded in the cluster log in the window.

Cluster service command | Shortcut command | Action
/debugresmon | /DR | Enables the debugging of the resource dynamic-link libraries (DLLs) that are loaded by the resource monitor process.
/fixquorum | /FQ | Allows the Cluster service to start up, despite problems with the quorum device.
/resetquorumlog | /RQ | If the quorum log file is not found or is corrupted, creates a new quorum log file based on information in the local node's cluster database file. If the quorum log file is found and is not corrupted, this command has no effect.
/norepevtlogging | n/a | Allows no replication of event log entries.
/forcequorum /FO Restores quorum for a majority node set server cluster that has lost quorum.

Note

  • It is recommended that you use the method described in To force quorum in a majority node set server cluster instead of the clussvc /debug /forcequorum command option described here.

For more information on commands for the Cluster service, see:

  • debugresmon command
  • fixquorum command
  • resetquorumlog command
  • norepevtlogging command
  • forcequorum command


Debugresmon command

The debugresmon command helps you to debug the resource monitor process and, therefore, the resource dynamic-link libraries (DLLs) that are loaded by the resource monitor. You can use any standard Windows-based debugger, such as Microsoft Developer Studio.

The syntax is:

clussvc /debug /debugresmon

or

clussvc /debug /DR

Note

  • The debugresmon command can be used only when starting the cluster service in the command prompt window. The debugresmon command cannot be used as a start parameter when starting the cluster service in the Computer Management console.
Just before the resource monitor process is started up, the cluster service issues the message:

"Waiting for debugger to connect to the resmon process x"

where x is the process identification number (PID) of the resource monitor process.

After the resource monitor process has started and you have attached a debugger to the resource monitor process, the Cluster service continues with its initialization.

For more information on the Resource Monitor, see Resource Monitors.

For more information on resource DLLs, see Resource dynamic-link libraries (DLLs).

For more information on debugging resource DLLs, see the Microsoft Software Development Kit (SDK).


Fixquorum command

The fixquorum command allows you to start the cluster service even if there are problems with the quorum resource. Only one node at a time can be started with this command. You cannot join any other nodes to the node started using this command.

The syntax is:

clussvc /debug /fixquorum

or

clussvc /debug /FQ

Preferably, you can use the fixquorum command as a start parameter when starting the cluster service in the Computer Management console. For more information, see To set the Cluster service to only start manually.

When the fixquorum command is issued on a particular node, the Cluster service starts, but all the resources, including the quorum resource, remain offline. This allows you to then manually bring the quorum resource online and more easily diagnose quorum device failures. You can use this command, for example, if you need to switch from a problematic quorum disk to another quorum resource. For more information, see To use a different disk for the quorum resource.


Resetquorumlog command

The resetquorumlog command creates a new quorum log file, if missing or corrupted, using information stored in the local node's cluster database and creates a new registry checkpoint file. The new quorum file is created using information in the cluster database located in %systemroot%\cluster\CLUSDB. If the quorum log file is not missing or corrupt, this command has no effect.

The syntax is:

clussvc /debug /resetquorumlog

or

clussvc /debug /RQ

The resetquorumlog command can also be set as a start parameter when starting the cluster service in the Computer Management console.

Caution

  • The information retrieved from the cluster database might be outdated. Therefore, use this command only if there are no backups of the quorum log file available. You must use the Backup or Restore Wizard even if you do not have a backup of the quorum log. For more information on restoring server cluster data using the Backup or Restore Wizard, see Server cluster backup and restore.

    For more information on recovering from a corrupted quorum log, see Recover from a corrupted quorum log or quorum disk.

Note

  • The registry checkpoint file created by the resetquorumlog command has the format CHKxxx.TMP.


Norepevtlogging command

The norepevtlogging command prevents replication of those events recorded in the event log. This command is useful in reducing the amount of information displayed in the command window by filtering out events already recorded in the event log.

The syntax is:

clussvc /debug /norepevtlogging

The norepevtlogging command can also be set as a start parameter when starting the cluster service in the Computer Management console.

For example, to start the cluster service and log those events not recorded in the event log to a local file, Debugnorep.log:

clussvc /debug /norepevtlogging > c:\DEBUGNOREP.log\

For more information on event logs, see Event Log overview.


Forcequorum command

The forcequorum command restores quorum for a majority node set server cluster that has lost quorum. This command is useful if a partition of a geographically dispersed server cluster (for example all the nodes in one location) has lost communication with the nodes at another location.

The syntax is:

clussvc /debug /forcequorum node list

or

clussvc /debug /FO node list

For example, to start the cluster service on nodes Node1, Node2, and Node3, type:

clussvc /debug /forcequorum Node1,Node2,Node3

Important

  • When you force quorum in a majority node set cluster, an error message from the Service Control Manager may appear, indicating that the Cluster service failed to start. You can safely ignore this message at this time; the Cluster service will continue startup after the end of the startup timeout period for Service Control Manager.

Note

  • It is recommended that you use the method described in To force quorum in a majority node set server cluster instead of the clussvc /debug /forcequorum command option described here.


Resources

  • For a good technical reference on clustering technologies, see Pfister, Gregory F. In Search of Clusters. Upper Saddle River, NJ: Prentice Hall, 1998.
  • For information on XOX or XOX, see the Microsoft Web site (http://www.microsoft.com/).
  • Microsoft maintains up-to-date Windows Server 2003 family product documentation at the Microsoft Web site (http://www.microsoft.com). This site has information that is more current than the Help documentation on your product CD.
  • For technical support information on server clusters, see Updated technical information.
  • The Microsoft Windows Resource Kits contain additional technical, planning, and deployment information on server clusters. For more information about server cluster deployments, see "Planning for High Availability" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/).
  • For a detailed description of how a business has used Network Load Balancing clusters and server clusters to improve performance and availability of their Web site and other services, refer to the clustering scenario at the Microsoft Web site.
  • Requests for Comments (RFCs) are an evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. Standards are defined in RFCs published by the Internet Engineering Task Force (IETF) and other working groups. For more information on private IP network addresses, see RFC 1918: Address Allocation for Private Internets.

    You can obtain RFCs from the RFC Editor Web site.

    XOX

  • Cluster Administrator supports command-line parameters. If you start Cluster Administrator from the command line, you can connect to one or more clusters by specifying the cluster name, the name of one of the cluster nodes, or the name of a cluster IP address.

    When you specify the clusters to connect to using the Cluster Administrator command line, Cluster Administrator will not try to restore your most recent cluster connections. You can also prevent Cluster Administrator from restoring your most recent cluster connections by specifying the cluadmin /noreconnect command at the command line.

    For more information on administering a cluster from the command line, see Managing a server cluster from the command line.

  • The following links point to information that may help you better understand server clusters within the overall context of Windows Clustering.

    For information on the solutions that make up Windows Clustering, see Windows Clustering.

    For information on Network Load Balancing clusters, see Network Load Balancing clusters.

    For information on server clusters and how they work with Network Load Balancing clusters, see Updated technical information.

  • Server clusters support unattended setup, a feature of Windows Server 2003 family operating systems.

    For information about unattended setup, see Planning for unattended setup.


Troubleshooting

This section provides symptom-based diagnostic procedures for troubleshooting clustering problems. You can also use the Cluster Diagnostics and Verification Tool (ClusDiag) to run diagnostic tests. These tests will help you verify the functionality of a cluster and troubleshoot cluster failures using the generated log files. ClusDiag is available in the Microsoft Windows Server 2003 Resource Kit and at the Microsoft Download Center at the Microsoft Web site (http://www.microsoft.com/). For information about how to obtain product support, see Technical support options.

This section covers:

  • Additional New Server Cluster Wizard Information
  • Cluster installation problems
  • Cluster disk and drive connection problems
  • Node-to-node connectivity problems
  • Client-to-cluster connectivity problems
  • Group and resource failure problems
  • File and print server cluster problems
  • General administrative problems


Additional New Server Cluster Wizard Information

Problems that occur when you use the New Server Cluster Wizard to create a new server cluster are usually the result of misconfigured cluster networks and hardware or permissions issues with the Cluster service account. You can use the information in this topic to help diagnose and troubleshoot these problems.

This topic contains overviews of clustering technology, additional information on error and event log messages, step-by-step implementation guides, scenarios, top troubleshooting issues, and relevant Knowledge Base (KB) articles from the Microsoft Product Support Services Web site.

Top Troubleshooting Issues

  • Cluster installation problems
  • Cluster disk and drive connection problems
  • Node-to-node connectivity problems
  • Client-to-cluster connectivity problems
  • Group and resource failure problems
  • General administrative problems

Error and Event Log Messages

To search for additional information on error and event log messages, click Error and Event Log Messages in Help and Support Center.

Top Knowledge Base (KB) articles

For information about server clusters, see the following key articles in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)
Problem Area | Key KB Article # | Title
Understanding virtual servers | Q257932 | Using Microsoft Cluster Server to Create a Virtual Server (http://search.support.microsoft.com/kb/)
Event 1034 occurs when replacing a shared SCSI disk | Q280425 | Recovering from an Event ID 1034 on a Server Cluster (http://search.support.microsoft.com/kb/)
Network configuration errors | Q259267 | Microsoft Cluster Service Installation Resources (http://search.support.microsoft.com/kb/)
Creating clustered home folders | Q256926 | Implementing Home Folders on a Server Cluster (http://search.support.microsoft.com/kb/)
Setting up clustered printers | Q197046 | How to Set up a Print Spooler on Microsoft Cluster Server (http://search.support.microsoft.com/kb/)
Starting the Cluster service | Q262962 | Cluster Service Does Not Start with Event ID 7000: Not Responding to Control Function (http://search.support.microsoft.com/kb/)
Accessing cluster disks | Q275704 | Cluster Disks May Be Incorrectly Accessible from All Nodes (http://search.support.microsoft.com/kb/)
Setting up "heartbeat" configurations for private networks | Q258750 | Recommended Private "Heartbeat" Configuration on Cluster Server (http://search.support.microsoft.com/kb/)
Setting up Cluster service account permissions | Q269229 | How to Manually recreate the Cluster Service Account (http://search.support.microsoft.com/kb/)
  • For a list of the top server cluster support issues, see the Microsoft Web site (http://www.microsoft.com/)

  • To find other relevant articles, search the Microsoft Knowledge Base (http://search.support.microsoft.com/kb/) using the keywords server cluster.

Help Topics

  • For a checklist of the steps to follow when creating a new server cluster or adding a node to an existing cluster, see Checklist: Planning and creating a server cluster.
  • For an overview of server clusters, see Server clusters overview.
  • For an overview of the three complementary Microsoft Windows Clustering technologies (server clusters, Network Load Balancing, and Component Load Balancing), see Windows Clustering.

Step-by-Step Implementation Guides and Scenarios

  • For a tutorial on Cluster Installation, see the Microsoft Web site (http://www.microsoft.com/).
  • For example deployments of Windows Clustering, see "Planning for High Availability" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/).


Cluster installation problems

The Cluster Installation troubleshooting section of Getting Started will help you diagnose and solve problems creating a cluster and adding one or more nodes to an existing cluster.

For more information on troubleshooting cluster installation issues, see Knowledge Base article Q295648, "How to Analyze the Cluster Configuration Log Files" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

For information about how to obtain product support, see Technical support options.


Cluster disk and drive connection problems

What problem are you having?

When the physical disks are not powering up or spinning, Cluster service cannot initialize any quorum resources.

Cause: Cables are not correctly connected, or the physical disks are not configured to spin when they receive power.

Solution: After checking that the cables are correctly connected, check that the physical disks are configured to spin when they receive power.

The Cluster service fails to start and generates an Event ID 1034 in the Event log after you replace a failed hard disk, or change drives for the quorum resource.

Cause: If a hard disk is replaced, or the bus is reenumerated, the Cluster service may not find the expected disk signatures, and consequently may fail to mount the disk.

Solution: Write down the expected signature from the Description section of the Event ID 1034 error message. Then follow these steps:

  1. Backup the server cluster.
  2. Set the Cluster service to start manually on all nodes, and then turn off all but one node.
  3. If necessary, partition the new disk and assign a drive letter.
  4. Use the confdisk.exe tool (available in the Microsoft Windows Server 2003 Resource Kit) to write that signature to the disk.
  5. Start the Cluster service and bring the disk online
  6. If necessary, restore the cluster configuration information.
  7. Turn on each node, one at a time.
For information on replacing disks in a server cluster, see Knowledge Base article Q305793, "How to Replace a Disk with Windows 2000 or Windows Server 2003 family Clusters" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

Drive on the shared storage bus is not recognized.

Cause: Scanning for storage devices is not disabled on each controller on the shared storage bus.

Solution: Verify that scanning for storage devices is disabled on each controller on the shared storage bus.

Many times, the second computer you turn on does not recognize the shared storage bus during the BIOS scan if the first computer is running. This situation can manifest itself in a "Device not ready" error being generated by the controller, or in substantial delays during startup.

To correct this, disable the option to scan for devices on the shared controller.

Notes

  • This symptom can manifest itself as one of several errors, depending on the attached controller. It is normally accompanied with a one- to two-minute start delay and an error indicating the failure of some device.

Configuration cannot be accessed through Disk Management.

Under normal cluster operations, the node that owns a quorum resource locks the drive storing the quorum resource, preventing the other nodes from using the device. If you find that the cluster node that owns a quorum resource cannot access configuration information through Disk Management, the source of the problem and the solution might be one of the following:

Cause: A device does not have physical connectivity and power.

Solution: Reseat controller cards, reseat cables, and make sure the drive spins up when you start.

Cause: You attached the cluster storage device to all nodes and started all the nodes before installing the Cluster service on any node.

Solution: After you attach all servers to the cluster drives, you must install the Cluster service on one node before starting all the nodes. Attaching the drive to all the nodes before you have the cluster installed can corrupt the file system on the disk resources on the shared storage bus.

SCSI or fibre channel storage devices do not respond.

Cause: The SCSI bus is not properly terminated.

Solution: Make sure that the SCSI bus is not terminated early and that the SCSI bus is terminated at both ends.

Cause: The SCSI or fibre channel cable is longer than the specification allows.

Solution: Make sure that the SCSI or fibre channel cable is not longer than the cable specification allows.

Cause: The SCSI or fibre channel cable is damaged.

Solution: Make sure that the SCSI or fibre channel cable is not damaged. (For example, check for bent pins and loose connectors on the cable and replace it if necessary.)

Disk groups do not move or stay online pending after move.

Cause: Cables are damaged or not properly installed.

Solution: Check for bent pins on cables and make sure that all cables are firmly anchored to the chassis of the server and drive cabinet.

Disks do not come online or Cluster service does not start when a node is turned off.

Cause: If the quorum log is corrupted, the Cluster service cannot start.

Solution: If you suspect the quorum resource is corrupted, see the information on the problem "Quorum log becomes corrupted" in Node-to-node connectivity problems.

Drives do not fail over or come online.

Cause: The drive is not on a shared storage bus.

Solution: If drives on the shared storage bus do not fail over or come online, make sure the disk is on a shared storage bus, not on a nonsystem bus.

Cause: If you have more than one local storage bus, some drives in Shared cluster disks will not be on a shared storage bus.

Solution: If you do not remove these drives from Shared cluster disks, the drives do not fail over, even though you can configure them as resources.

Shared cluster disks is in the Cluster Application Wizard.

Mounted drives disappear, do not fail over, or do not come online.

Cause: The clustered mounted drive was not configured correctly.

Solution: Look at the Cluster service errors in the Event Log (ClusSvc under the Source column). You need to recreate or reconfigure the clustered mounted drive if the description of any Cluster service error is similar to the following:

Cluster disk resource "disk resource": Mount point "mount drive" for target volume "target volume" is not acceptable for a clustered disk because reason. This mount point will not be maintained by the disk resource.

When recreating or reconfiguring the mounted drive(s), follow these guidelines:

  • Make sure that you create unique mounted drives so that they do not conflict with existing local drives on any node in the cluster.
  • Do not create mounted drives between disks on the cluster storage device (cluster disks) and local disks.
  • Do not create a mounted drive from a clustered disk to the cluster disk that contains the quorum resource (the quorum disk). You can, however, create a mounted drive from the quorum disk to a clustered disk.
  • Mounted drives from one cluster disk to another must be in the same cluster resource group, and must be dependent on the root disk.

For more information on viewing the Event Log, see View event logs.

For more information on creating mounted drives in a server cluster, see To add drives on the shared storage bus.

The cluster quorum disk (containing the quorum resource) becomes disconnected from all nodes in a cluster and you are later unable to add the nodes back to the cluster.

See the solution for the identically titled problem in Node-to-node connectivity problems.

For information about how to obtain product support, see Technical support options.

It is important that you correctly configure the storage topology (for example, SCSI, Fibre Channel, Storage Area Networks) and the storage interconnects (for example, multiple paths) used in your server cluster. Before deploying your server cluster, contact your hardware vendors to ensure that your particular cluster storage configuration is supported at the hardware level. For descriptions of supported cluster storage topologies, best practices for deploying and managing cluster storage, and a list of cluster storage-related Knowledge Base articles, see the cluster storage information at the Microsoft Web site.(http://www.microsoft.com/)


Node-to-node connectivity problems

What problem are you having?

I cannot complete a cluster on the first node.

Cause: XOX or XOX is incorrectly installed.

Solution: Make sure that XOX or XOX is correctly installed.

Cause: Your hardware is not listed in the Cluster category on the Microsoft Windows Catalog.

Solution: Make sure that your hardware is listed on the Microsoft Windows Catalog. See the Windows Catalog at Support resources. Search for "Cluster".

If any of the hardware you are using for your cluster is not on this list, consider replacing those components with hardware that is listed.

Cause: You have chosen individual components from the Windows Catalog instead of systems.

Solution: Do not choose individual components of your cluster from the Microsoft Windows Catalog. Microsoft supports only systems chosen from this list.

Cause: Your primary Internet protocol (IP) address is invalid.

Solution: If the node uses DHCP to obtain noncluster IP addresses, use Ipconfig.exe to verify that you have a valid primary IP address for all network adapters. If the second IP address listed (the subnet mask) is 0.0.0.0, your primary address is invalid.

When the resources fail over and the nodes do not detect each other, there is no connectivity between the nodes or with the cluster storage device.

Cause: The Remote Procedure call (RPC) service is not running.

Solution: On each node, use Services in Control Panel to confirm that the RPC service is running.

Cause: The nodes do not have RPC connectivity.

Solution: Verify that the nodes have RPC connectivity.

You can determine this by using a network analyzer (such as Network Monitor), or you can use RPCPing (available on the Microsoft Exchange Server CD)

Quorum resource does not start.

Cause: The resource is not physically connected to the server.

Solution: Make sure that the resource is physically connected to the server.

Quorum resource fails.

Cause: The disk on the shared bus holding the quorum resource has failed.

Solution: If the disk on the shared bus holding the quorum resource fails and cannot be brought online, the Cluster service cannot start. To correct this situation, you must use the fixquorum option to start the Cluster service on a single node, and then use Cluster Administrator to configure the Cluster service to use a different disk on the shared bus for the quorum resource.

When fixquorum is specified, the Cluster service starts without a quorum resource, and does not bring the quorum disk online. A node cannot join a cluster when the Cluster service is running with the fixquorum option.

For instructions on how to change the disk that the Cluster service uses for the quorum resource, see To use a different disk for the quorum resource.

Quorum log becomes corrupted.

Cause: This may occur for a variety of reasons.

Solution: If the quorum log is corrupted, the Cluster service attempts to correct the problem by resetting the log file. In this case, the Cluster service writes the following message in the system log:

The log file [name] was found to be corrupt. An attempt will be made to reset it.

If the quorum log cannot be reset, the Cluster service cannot start.

If the Cluster service fails to detect that the quorum log is corrupted, the Cluster service may fail to start. In this case, there may be an "ERROR_CLUSTERLOG_CORRUPT" message in the system log.

To correct this, you must use the noquorumlogging option when starting the Cluster service to temporarily run the Cluster service without quorum logging. You can then correct the disk corruption and delete the quorum log, as necessary. When noquorumlogging is specified, the Cluster service brings the quorum disk online, but disables quorum logging. You can then run Chkdsk on your quorum disk to detect and correct disk corruption.

For instructions on how to recover from a corrupted quorum log or quorum disk, see To recover from a corrupted quorum log or quorum disk.

Additional node cannot join the cluster.

Cause: The cluster configuration on the node may not have been completely removed if the node was previously evicted.

Solution: At a command prompt, type cluster [cluster name] node node name /forcecleanup.

When an additional node fails to join a cluster, improper name resolution is often the cause. The problem may exist because of invalid data in the WINS cache. You may also have the wrong binding on the WINS or DNS Services for the additional node.

If WINS or DNS is functioning correctly on all nodes:

Cause: You may not be using the proper cluster name, node name, or IP address.

Solution: Confirm that you are using the proper cluster name, node name, or IP address.

When joining a cluster, you can specify the cluster name, the computer name of the first node, or the IP address of either the cluster or the first node.

Cause: The Cluster Name resource may not have started.

Solution: Confirm that the Cluster Name resource started.

Use Cluster Administrator on the first node to ensure that the Cluster Name resource is running.

Cause: The Cluster service may not be running on the first node.

Solution: Confirm that the Cluster service is running on the first node and that all resources within the Cluster Group are online before installing a second node.

The Cluster service may not have yet started when you attempted to join the cluster.

Cause: Network connectivity may not exist between the nodes.

Solution: Confirm that network connectivity exists between the nodes.

Make sure TCP/IP is properly configured on all nodes.

Cause: You may not have IP connectivity to the cluster address.

Solution: Confirm that you have IP connectivity to the cluster address and that the IP address is assigned to the correct network.

If you cannot ping the IP address of the cluster, run Cluster Administrator on the first node and ensure the cluster IP Address resource is running. Also, use Cluster Administrator to ensure that the cluster has a valid IP address and subnet mask (click Cluster Group, right-click Cluster IP Address, and click Properties), and that the IP address does not conflict with an IP address that is already in use on the network. If the address is not valid, change it, take the Cluster IP Address resource offline, and then bring it online again. If the IP address is not assigned to the correct network, use Cluster Administrator to correct the problem.

If your cluster nodes use DHCP to obtain noncluster IP addresses, use Ipconfig.exe to verify that you have a valid primary IP address for the networks in question. If the second IP address listed (the subnet mask) is 0.0.0.0, your primary address is invalid.

Cause: The network role may have changed from Use for all communication.

Solution:Confirm that the network role has not been changed from Use for all communication.

A network role is initialized to Use for all communications but can be changed by the administrator. After verifying that you have IP connectivity to the cluster address and that the IP address is assigned to the correct network, use Cluster Administrator to confirm that at least one of the networks connected between the nodes is enabled to Use for all communications. To verify the role in Cluster Administrator, open the Networks folder, right-click Network, and then click Properties. Use for all communications enables the network to have both node-to-node communication and client-to-cluster communication.

For more information on networks, see Server cluster networks. For more information on network roles, see Configuring cluster network hardware. To use Cluster Administrator to reset the network's role to Use for all communications, see To enable a network for cluster use.

Nodes cannot connect to the cluster drives.

Cause: The same drive letters may not have been assigned to the cluster drives on all nodes.

Solution: Confirm that the cluster drives are assigned the same drive letters on all nodes.

To do so, run Disk Management on each node and make sure that identical drive letters are assigned to all cluster drives.

Where?

  • Computer Management
  • Storage
  • Disk Management

Cause: The node may not be physically connected to the cluster drive.

Solution: Confirm that the node is physically connected to the cluster drive.

If it is not, shut down all nodes and the cluster drive. Connect the nodes to the shared storage bus. Then, start the cluster drive and start the first node. After the Cluster service starts on the first node, start the additional nodes, and attempt to connect to the cluster drive.

Cause: If you are using a shared SCSI bus, the SCSI devices may not have unique IDs.

Solution: Verify that each SCSI device has a unique ID. SCSI controller IDs are preset to seven. Reset one SCSI controller ID to six.

Cause: The controllers on the shared storage bus may not be correctly configured.

Solution: Confirm that the controllers on the shared storage bus are correctly configured (with all cards configured to transfer data at the same rate).

Cause: The devices and controllers may not match.

Solution: Confirm that your devices and controllers match.

For example, do not use a wide connection controller on one node and a narrow connection controller on another node. It is also recommended that all fibre channel controllers be homogeneous, so do not use different brands of controllers together.

The cluster quorum disk (containing the quorum resource) becomes disconnected from all nodes in a cluster and you are later unable to add the nodes back to the cluster.

Cause: The cluster configuration on the nodes may not have been completely removed.

Solution #1: Use the cluster.exe node /force[cleanup] command to evict the nodes from the cluster. For more information, see To evict a node from the cluster.

Solution #2: Use the Cluster service fixquorum start up parameter to start the Cluster service. Only one node at a time can be started with this command. You cannot join any other nodes to the node started using this command. For more information, see To recover from a corrupted quorum log or quorum disk.

For information about how to obtain product support, see Technical support options.


Client-to-cluster connectivity problems

What problem are you having?

Clients cannot connect to virtual servers.

Cause: The client might not be using the correct network name or IP address to access the cluster.

Solution: Make sure that the client is accessing the cluster using the correct network name or IP address.

Cause: The client might not have the TCP/IP protocol correctly installed and configured.

Solution: Make sure that the client has the TCP/IP protocol correctly installed and configured.

Depending on the application being accessed, the client can address the cluster by specifying either the resource network name or the IP address. In the case of the network name, you can verify proper name resolution by checking the NetBT cache (using the Nbtstat.exe utility) to determine whether the name had been previously resolved. Also, confirm proper WINS configuration, both at the client and through the WINS Administrator.

If the client is accessing the resource through a specific IP address, ping the IP address of the cluster resource and cluster nodes from a command prompt.

For more information on Nbtstat.exe, see Nbtstat.

For instructions on how to troubleshoot connectivity problems, see To troubleshoot client-to-virtual server connectivity.

Cause: The client may be attempting to connect to an incorrect node after a failover.

Solution: Make sure that the routers are configured correctly. For more information, see article Q244331, "MAC Address Changes for Virtual Server During a Failover with Clustering" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

Clients cannot access resources.

Cause: Both your private network and the primary network are down.

Solution: If your server cluster nodes are multihomed and use a private network to communicate, the primary network can be down and the Cluster service can still function normally.

If the private network is lost between nodes, resources that are configured to do so will fail over to the node that has ownership of the quorum resource. Each of the other nodes will stop its Cluster service.

Cause: A node might have lost connectivity with the network.

Solution: If you suspect a node has lost connectivity with the network:

  • Confirm that the connection configuration settings are correct for each connection. To do this, open Control Panel, then double-click Network Connections. Right-click a connection and click Properties.
  • Check WINS or DNS to make sure that they are properly configured.
  • Confirm that the static IP addresses being used by the Cluster service are still in place and are not being used by other resources on the network.

A node cannot communicate on a network.

Cause: If a node cannot communicate on a network, it might lack a physical connection to the other nodes, or the other nodes might not be connected to one another.

If the cabling has failed, the Cluster service might not have received the heartbeat of the node and so failed the resources owned by that node over to other nodes in the cluster. The node can no longer communicate to clients on a network.

Solution: Check the hub and local cabling, both to the network and to the cluster disks.

Clients cannot access a group that has failed over.

Cause: There might not be a physical connection between the cluster nodes and the group that failed over has also failed to come online.

Solution -- step 1: Confirm that you have a physical connection between the cluster nodes.

  • Make sure that the network cabling has not failed or been damaged.

    If the cabling has failed, the Cluster service might have failed over the resources to another node.

  • Ensure that the storage device cabling has not failed.
  • If the nodes are separated by one or more hubs, check the connectivity through all hubs.

Solution -- step 2: Bring the group back online.

Clients cannot attach to a cluster file share resource.

Cause: WINS or DNS might not be correctly configured.

Solution: Make sure that WINS or DNS are correctly configured.

If you are using WINS, run WINS Manager on the WINS server; then, on the Mappings menu, click Show Database. Make sure that each node and the cluster are registered in the WINS database and that the registrations are active.

For more information on WINS and WINS Manager, see the Networking Guide in the Microsoft Windows Server 2003 Resource Kit.

Cause: Your security policies might not allow the client to access the file share.

Solution: Make sure that your security policies allow the client to access the file share.

The client must have the right to log on to the file share, or the Guest account must be enabled for the client to have access.

Clients cannot access a cluster resource.

Cause: Either the IP Address resource or Network Name resource for the group in which the resource is contained is not online.

Solution: Check the group dependencies; the resource is supposed to be dependent on either the IP Address or the Network Name resource. Ensure that the IP Address and Network Name resources are online in the resource group. From the client computer, try to ping the IP addresses of the virtual server and individual nodes.

Cause: Either the client or the cluster computer is not configured for either WINS or DNS.

Solution: Make sure that the cluster nodes are configured properly for name resolution using either WINS or DNS, and make sure that clients are configured to use the same form of name resolution.

Cause: The client is attempting to access the cluster from a different subnet, and DNS is not correctly configured.

Solution: Configure the cluster nodes and client computer to use WINS or DNS. If you use DNS, add a DNS address record for the cluster in the DNS database.

Client can detect all nodes but cannot detect a virtual server.

Cause: The virtual server might not have its own IP Address and Network Name resources.

Solution: Make sure that the virtual server has its own IP Address and Network Name resources, and that both resources are online.

Your servers must have an address and a name on the network for any other server or client to properly recognize that the servers are on the network.

Cause: One or more nodes are not correctly configured to use WINS or DNS.

Solution: Make sure that all nodes are correctly configured to use WINS or DNS.

Clients cannot connect to a virtual server and the system event logs on the client computers contain Kerberos authentication errors.

Cause: The cluster might have used a previously-created computer object for the virtual server. When the virtual server's Network Name resource is brought online for the first time after Kerberos support has been enabled, the cluster changes the object's password. Active Directory then replicates this change to all domain controllers in the cluster. However, because of replication latencies, clients connecting to this virtual server might receive a Kerberos ticket encrypted with the old password. This can result in Kerberos authentication errors.

Solution: Wait until the new password has been replicated to all domain controllers, or force replication using the repadmin and replmon command-line tools, available in the \Support\Tools folder on your operating system installation CD.

For information on monitoring and troubleshooting replication issues, see Troubleshooting replication.

For information about how to obtain product support, see Technical support options.


Group and resource failure problems

What problem are you having?

A resource fails, but is not brought back online.

Cause: A resource may depend on another resource that has failed.

Solution: In the resource Properties dialog box, make sure that the Do not restart check box is clear. If the resource needs another resource to function, and if the second resource fails, confirm that the dependencies are correctly configured.

You cannot bring a resource online.

Cause: The resource is not properly installed.

Solution: Make sure the application or service associated with the resource is properly installed.

Cause: The resource is not properly configured.

Solution: Make sure the properties are set correctly for the resource.

Cause: The resource is not compatible with server clusters.

Solution: Not all applications can be configured to fail over in a cluster. For more information, see Choosing applications to run on a server cluster.

Cause: The resource is generating a specific error.

Solution: Review the system Event Log (look for ClusSvc entries under the Source column) to see if that resource is generating a specific error message.

You cannot bring the default physical disk resource online in Cluster Administrator.

Most cluster configuration problems result from improper configuration of the shared storage bus or the restart of servers.

Cause: You may not have restarted the servers after installing the Cluster service.

Solution: Make sure that you restarted all servers after installing the Cluster service.

When the servers are restarted, the signature of each disk in the cluster storage is read, and the registries are updated with the signature information.

Cause: There may be hardware errors or transport problems.

Solution: Make sure that there are no hardware errors or transport problems.

Using Event Viewer (on the Start menu, under Programs and Administrative Tools (Common)), look in the event log for disk I/O error messages or indications of problems with the communications transport.

Cause: You may not have waited long enough for the registries to be updated.

Solution: Make sure that you waited long enough for the registries to be updated.

Cluster Administrator takes a backup of the registry when it starts up. However, it can take up to a minute after the second server restarts for the disk signatures to be written to the registries. Wait a minute, and then click Refresh.

Cause: One or more adapters on the shared storage bus are configured incorrectly.

Solution: Make sure that the adapters are configured correctly.

Cause: The shared storage bus exceeds the maximum cable length.

Solution: Make sure that the shared storage bus does not exceed the maximum cable length.

Cause: The disk is not supported.

Solution: Make sure that the disk hardware or firmware revision level is not outdated.

Cause: The bus adapter is not supported, or the adapter hardware or firmware revision level is outdated.

Solution: Make sure that the bus adapter is supported, and that the adapter hardware or firmware revision level is current.

Cause: If you move your storage bus adapter to another I/O slot, add or remove bus adapters, or install a new version of the bus adapter driver, the cluster software may not be able to access disks on your shared storage bus

Solution: To accommodate these changes, make sure that your shared storage bus adapter has been properly reconfigured.

Cause: The operating system is incorrectly configured to access the shared storage bus.

Solution: Verify that the operating system can detect the shared storage bus adapter.

In Disk Management, you do not see the disk for the group that is online on that node.

Where?

  • Computer Management
  • Storage
  • Disk Management

Cause: You may not be looking at the right disks.

Solution: Make sure that you are looking at the right disks.

If you have not labeled your disks or assigned fixed drive letters to them, you may not recognize which disks are part of the cluster and which ones are not. Label your disks in a meaningful manner and assign fixed drive letters to all partitions.

Cause: There may have been hardware problems.

Solution: Make sure that there have not been any hardware problems.

Run Event Viewer and check for disk I/O error messages or indications of hardware problems.

You are unable to manually move a group, or it does not fail over to another node when it is supposed to.

Cause: The fail over node may not be designated as a possible owner for all resources in the group that you want to fail over.

Solution: Make sure that the fail over node is designated as a possible owner for all resources in the group you want to fail over.

Check the ownership configuration in the group resource Properties dialog box. If the node is not set as a possible owner for all resources in the group, the node cannot own the group, so failover will not occur. To fix this, make the node a possible owner for all resources in the group.

Cause: A resource in the group may be continually failing.

Solution: Determine if a resource in the group is continually failing.

If the node can, it will bring the resource back up without failing over the group. If the resource continually fails but does not fail over, make sure that the resource property Restart and affect the group is selected. Also, check the Restart Threshold and Restart Period settings, which are also in the resource Properties dialog box.

A group failed over but did not fail back.

Cause: The group will only fail back if the node the group was running on itself failed and then rejoined the cluster. If the group, but not the node, failed, then the group will fail over to another node, but will not fail back to the original node.

Cause: The failback policies of both the group and the resources may not be properly configured.

Solution: Make sure that the Prevent failback check box is clear in the group Properties dialog box. If the Allow failback check box is selected, be sure to wait long enough for the group to fail back. Check these settings for all affected resources within a group. Because groups fail over as a whole, one resource that is prevented from failing back affects the entire group.

Cause: The node to which you want the group to fail back is not configured as the preferred owner of the group.

Solution: Make sure that the node to which you want the group to fail back is configured as the preferred owner of the group. If not, the Cluster service leaves the group on the node to which they failed over.

The entire group failed and has not restarted.

Cause: A node is offline.

Solution: Make sure that the node is not offline.

If the node on which the group had been running is offline, check that another node is a possible owner of the group and of every resource in the group.

Cause: The group has failed repeatedly.

Solution: The group may have exceeded its failover threshold or its failover period. Try to bring the resources online individually (following the correct sequence of dependencies) to determine which resource is causing the problem. Or, create a temporary resource group (for testing purposes) and move the resources to it, one at a time.

All nodes are functioning, but resources fail back repeatedly.

Cause: Power may be intermittent or failing.

Solution: Ensure that your power is not intermittent or failing. You can correct this by using an uninterruptable power supply (UPS) or, if possible, by changing power companies.

The Cluster service does not successfully fail over resources.

Cause: Cluster storage device is not properly configured.

Solution: Verify that the cluster storage device is properly configured and that all cables are properly connected.

You fail over a resource group from one node to another, but it automatically fails back.

Cause: One or more resources fail to come online on the new node.

Solution: Use a process of elimination to determine which resource is failing to come online. For more information, see article Q303431, "Explanation of Why Server Clusters Do Not Verify that Resources will Work Properly on All Nodes" in the Microsoft Knowledge Base.(http://search.support.microsoft.com/kb/)

The Network Name resource fails when you change to a system locale that is different than the input language used by the Network Name resource.

Cause: The system locale must be the same on all nodes of a cluster and on the computer used to connect to the cluster.

Solution: Change the system locale. For more information, see To connect to a cluster with Cluster Administrator.

The Message Queuing resource fails to handle message activity correctly which may result in resource failures.

Cause: Each instance of Message Queuing on a server maps 4 MB of the system view space when handling message activity. This results in a default limit of three active, working instances of Message Queuing on a cluster node. In a server cluster with three Message Queuing resources, a node could have four concurrent Message Queuing services running (the service running on the local node plus the three services associated with the Message Queuing resources.) In this scenario, message activity could be limited, resulting in resource failures.

Solution: Increase the system view space memory pool on each node of a server cluster with three or more Message Queuing resources. (We also recommend that you increase the system view space memory pool even for nodes running fewer than three Message Queuing resources.)

  • Open Registry Editor.
  • Open the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
  • Create a new DWORD value called SystemViewSize.
  • Calculate and enter the data for this DWORD value using the following formula: (16 + (the number of Message Queuing resources x 4)).
    For example, the calculation result for a cluster with three Message Queuing resources is 28.
  • Reboot each node.

A third-party resource fails to come online in a mixed-version cluster or while upgrading a cluster.

Cause: If a resource uses a cryptographic provider not supplied by Microsoft to export (encrypt) and import (decrypt) resource data (cluster and cluster application cryptographic checkpoints), the default encryption key lengths may be different in the Windows 2000 and the Windows Server 2003 family operating systems. The result is that the resource might fail to come online and the cluster and event logs might contain cryptographic checkpoint synchronization errors for that resource.

Solution: Use the cluster.exe "CSP" private property to set the key length and effective key length for the third-party cryptographic provider that encrypts and decrypts data for the failing resource type.

  • Open Command Prompt.
  • Type cluster ClusterName "CSP"=key_length,effective_key_length:MULTISTR
    ClusterName is the name of the cluster, CSP is the name of the cryptographic provider, and key_length and effective_key_length are the key and effective key lengths for the RC2 encryption algorithm, in bits. For more information on using cluster.exe, see Cluster.
  • Depending on the resource, either bring the resource online or recreate the resource to add the new cryptographic checkpoint.

Note

  • Review the documentation for your cryptographic provider to obtain valid values for the following RC2 encryption algorithm parameters: key_length and effective_key_length. Also review the cryptographic provider documentation for the correct procedure for adding the cryptographic checkpoint.

For information about how to obtain product support, see Technical support options.


File and print server cluster problems

What problem are you having?

Clients cannot attach to a cluster file share resource.

Cause: WINS or DNS might not be correctly configured.

Solution: Make sure that WINS or DNS are correctly configured.

If you are using WINS, run WINS Manager on the WINS server; then, on the Mappings menu, click Show Database. Make sure that each node and the cluster are registered in the WINS database and that the registrations are active.

For more information on WINS and WINS Manager, see the Networking Guide in the Microsoft Windows Server 2003 Resource Kit.

Cause: Your security policies might not allow the client to access the file share.

Solution: Make sure that your security policies allow the client to access the file share.

The client must have the right to log on to the file share, or the Guest account must be enabled for the client to have access.

Clients cannot attach to a cluster printer share resource.

Cause: Not all printer ports may be used in a server cluster.

Solution: Use cluster-aware ports, for example LPR or Standard TCP/IP ports.

The LPR and Standard TCP/IP Port, both provided with Windows Server 2003 family operating systems, can be used in a server cluster. Check your printer documentation to verify that your printer can use one of these two ports.

For more information, see To create a cluster-managed printer.

After a resource failure, the clustered print server does not come back online.

Cause: The share name for the printer may also used by another printer in the cluster.

Solution: Choose a unique share name for the printer.

We recommend that you do not use the same share name for different printers, even if they are in a different resource group and associated with a different Print Spooler resource. In the event of a failure, the same node in the cluster may own both resource groups. If this occurs, printers that share a common name will not be available.

For information about how to obtain product support, see Technical support options.


General administrative problems

What problem are you having?

The Cluster service fails and the node cannot detect the network.

In this case, you probably have a configuration problem. Check the following:

Cause: Have you made any configuration changes recently?

Solution: If the node was recently configured, or if you have installed some resource that required you to restart the computer, make sure that the node is still properly configured for the network.

Cause: Is the node properly configured?

Solution: Check that the server is properly configured for TCP/IP. Also check that the appropriate services are running. If the node recently failed, there is an instance of failover; but, if the other nodes are misconfigured as well, the failover will be inadequate and client access will fail.

An IP address added to a group in the cluster fails.

Cause: The Internet protocol (IP) address is not unique.

Solution: The IP address must be different from every other group IP address and every other IP address on the network.

Cause: The IP address is not a static IP address.

Solution: The IP addresses must be statically assigned outside of a DHCP scope, or they must be reserved by the network administrator.

An IP address resource is unresponsive when taken offline, for example you are unable to query its properties.

Cause: You may not have waited long enough for the resource to go offline.

Solution: If an IP Address resource is unresponsive when taken offline, make sure that you wait long enough for the resource to go offline.

Certain resources take time to go offline. For example, it can take up to three minutes for the IP Address resource to go fully offline.

You receive the error: "RPC server is unavailable."

Cause: The server may not be operational, or the Cluster service and the RPC services may not be running.

Solution: If you receive the error "RPC Server is unavailable," make sure the server is operational and that both the Cluster service and the RPC services are running. Also, check the name resolution of the cluster; it is possible that you are using the wrong name or that the name is not being properly resolved by WINS or DNS.

Cluster Administrator cannot open a connection to a node.

Cause: The node may not be running.

Solution: If Cluster Administrator cannot open a connection to a node, make sure that the node is running. If it is, confirm that both the Cluster service and the RPC services are running.

An application starts but cannot be closed.

Cause: You may not have taken a resource offline using Cluster Administrator.

Solution: When you bring resources online using Cluster Administrator, you must also take those resources offline using Cluster Administrator; do not attempt to close or exit the application from the application interface.

A resource group has failed over but will not fail back.

Cause: The hardware and network configurations may not be valid.

Solution: Make sure that the hardware and network configurations are valid.

If any interconnect fails, failover can occur because the Cluster service does not detect a heartbeat, or it may not even register that the node was ever online. In this case, the Cluster service fails over the resources to the other nodes in the server cluster, but it cannot fail back because that node is still down.

Cause: The resource group may not have been configured to fail back immediately, or you are not troubleshooting the problem within the allowable failback hours for the resource.

Solution: Make sure that the resource group is configured to fail back immediately, or that you are troubleshooting the problem within the allowable failback hours for the resource group.

A group can be configured to fail back only during specified hours. Often, administrators prevent failback during peak business hours. To check this, use Cluster Administrator to view the resource failback policy.

Cause: You restarted the node to test the failover policy for the group instead of pressing the reset button.

Solution: Make sure that you press the reset button on the node. The resource group will not failback to the preferred node if you shutdown, then restart the node. For more information on testing failback policies, see To test node failure.

All nodes appear to be functioning correctly, but you cannot access all of the drives from one node.

Cause: The shared drive may not be functioning.

Solution: Confirm that the shared drive is still functioning.

Try to access the drive from another node. If you can do that, check the cable from the device to the node that you cannot perform the access. If the cable is not the problem, restart the computer and then try again to access the device. If you cannot access the drive, check your configuration.

Cause: The drive has completely failed.

Solution: Determine (from another node) whether the drive is functioning at all. You may have to restart the drive (by restarting the computer) or replace the drive.

The hard disk with the resource or a dependency for the resource may have failed. You may have to replace a hard disk. You may also have to reinstall the cluster.

Cluster Administrator update delays.

Cause: If you run Cluster Administrator from a remote computer, it may not display the correct (updated) cluster state when the cluster network name fails over from one node to another node. This can result in Cluster Administrator displaying a node as being online, when it is actually offline.

Solution: To work around this problem, restart Cluster Administrator.

You can avoid this problem by connecting to clusters through node names. However, if the node you are connected to fails, Cluster Administrator stops responding until the RPC connection times out.

Cluster Administrator stops responding when a node fails.

Cause: The Cluster Administrator may be slow in doing dynamic updates.

Solution: If Cluster Administrator stops responding when a node fails, make sure that Cluster Administrator is not just slow in doing dynamic updates. If the Cluster service is running on a remaining node, Cluster Administrator is either not responding or is updating very slowly. There are two ways to see if the Cluster service is running on a remaining node:

  • Use the TCP/IP Ping utility to ping the cluster name on a remaining node.
  • In Control Panel, double-click Services, and check whether the Cluster service is running.

Cannot connect to cluster from recent file list.

Cause: Files listed in the Cluster Administrator recent file list (both on the File menu and in the Open Connection to Cluster dialog box) have the cluster name appended to the path. For example, instead of Webclust1, the recent file list may list C:\Windows\Cluster\Webclust1. This problem occurs when Microsoft Visual C++ version 5.0 is installed.

Solution: To work around this problem, manually type the cluster name when you open the connection.

Node performance is sluggish and node fails.

Cause: CPU may be overloaded.

Solution: Check that your node is not processor-bound. That is, that the CPU is not running at 100-percent utilization. If you try to run too many resources for the node capacity, you can overload the CPU.

Also, review the size of your paging file. If the paging file is too small, the Cluster service can detect this as a node failure and fail over the groups.

The cluster log contains numerous resource informational messages (for example, Entered LooksAlive, Entered Open, Entered Offline).

Cause: One or more of your Generic Script resources fills the cluster log with multiple copies of Entered LooksAlive, Entered Open, Entered Offline messages.

Solution: When creating a script for a Generic Script resource, do not use the LogInformation method when calling the LooksAlive function. For more information, see the Microsoft Platform Software Development Kit (SDK).

The Cluster service fails to start and returns an error code of ERROR_SHARING_VIOLATION (32) with event ID 1144 (NM_EVENT_REGISTER_NETWORK_FAILED).

Cause: The Internet Assigned Numbers Authority (IANA)-assigned port (3343) used by the cluster network driver (ClusNet) is bound to another process, preventing the Cluster service from starting.

Solution: Use port scanning and process termination utilities to identify and end the process that is bound to port 3343. To do this:

  • Open Command Prompt.
  • Navigate to the %systemroot%\system32 directory.
  • Type netstat -a -o.

    This will display all listening and connected ports and the process ID of each process bound to that port. Port 3343 will appear for each cluster network on the node.

    • Notes

    • The -a option indicates that all connections and listening ports are supposed to be displayed. Server clusters uses UDP so the ports are normally in listening mode rather than in connections.
    • The -o option indicates that the owning process ID is supposed to be displayed.
  • Type tasklist.

    This will display the IDs for all the processes running on the node, including the process ID that matches the Cluster service (ClusSvc.exe).

  • Type taskkill /pid ID
    • to terminate the process(es) bound to port 3343 that do not match the ID for the Cluster service.

You cannot manually restore the cluster database on a local node by copying the systemroot\cluster\CLUSDB file from another node.

Cause: If the cluster registry hive is already locked and loaded by the Cluster service, the operating system will prevent you from copying a local CLUSDB file or overwriting an existing CLUSDB file on another node.

Solution: Stop the Cluster service. Then unload the HKEY_LOCAL_MACHINE\Cluster hive before restoring the cluster database file. To do this:

  • Open Command Prompt.
  • Type net stop clussvc to stop the Cluster service.
  • Use the Registry Editor to unload the hive under HKEY_LOCAL_MACHINE\Cluster. For more information, see To unload a hive from the registry.
The operating system will now allow you to copy the CLUSDB file from a node and manually restore it to another node.

For information about how to obtain product support, see Technical support options.


Change the quorum-resource location

Microsoft Windows graphic

To change the quorum-resource location

  1. Open Cluster Administrator.
  2. In the console tree, click the name of the cluster.
  3. On the File menu, click Properties, and then click the Quorum tab.
  4. In Quorum resource, click the disk resource you want to use as the quorum resource for the cluster.
  5. In Partition, if the disk has more than one partition, click the partition where you want the cluster specific data kept.
  6. In Root path, type the path to the folder on the partition; for example:

    \MSCS\

Notes

  • XOX
  • XOX
  • For 64-bit editions of XOX or XOX, cluster disks on a shared bus must be partitioned as MBR and not as GUID Partition Table disks.

Related Topics


Checklist: Installing an IIS Server Instance resource

Step | Reference
Review the concepts behind cluster resources. | Server cluster resources
Review resource groups and resource dependencies. | Groups
Review Internet Information Service (IIS) concepts. | Internet Information Services
Plan common resource settings. | Checklist: Creating a new resource
Note the type of Internet service you will provide: FTP or WWW. | Setting resource properties
Decide the IIS Server that the cluster will manage.

Important

  • It is recommended that you run the same version of IIS on all nodes in the cluster.
Setting resource properties
Create an IIS server instance resource. | Checklist: Creating a new resource
Configure IIS. | Internet Information Services
Synchronize IIS on all nodes by using the IIS Import/Export feature to copy the IIS configuration to other nodes. | Internet Information Services


Glossary of Clustering terms

availability

cluster.exe

cluster log

Cluster service

cluster storage

cluster-aware application

cluster-unaware application

failback

failback policies

failed

failover

failover policy

heartbeats

high availability

interconnect

node

offline

online

paused

pending

possible owners

public network

quorum log

quorum resource

resource

Resource Monitor

resource types

rolling upgrade

scalability

virtual server

Windows Clustering